Creating new images

DICOM Conformance Statement

In this appendix . . .

"MIPAV"

"MIPAV DICOM communications interface"
"Implementation model"

The purpose of this conformance statement is to facilitate communications and interoperations with the National Institutes of Health (NIH) Medical Image Processing, Analysis, and Visualization program (MIPAV).

This introduction describes the MIPAV application and briefly summarizes the Digital Imaging and Communications in Medicine (DICOM) standard services employed by MIPAV.

MIPAV

MIPAV is an n-dimensional, general purpose image-processing program designed to assist the NIH research and clinical communities in extracting quantitative information from various medical imaging modalities to better understand, diagnose, monitor, and treat medical disorders.

MIPAV, which is written in Java, takes advantage of the programming language's intrinsic object-oriented capabilities to improve code reuse, functionality, and portability. MIPAV is available on any Java-capable operating system, such as Windows, Macintosh, Irix, and Solaris.

Although this is a general purpose image-processing platform, Dr. McAuliffe presently uses this platform to develop specific and unique image processing techniques to meet the requirements of his collaborators.

MIPAV DICOM communications interface

The MIPAV DICOM communications interface automates the process of querying and retrieving DICOM standard formatted files. The transfer of images can be clumsy and time consuming when studies are manually transferred to removable media or even to File Transfer Protocol (FTP) access, which does not ensure file format compatibility. MIPAV allows you to transfer DICOM standard formatted images over the network using the DICOM communications protocol that runs over the Transmission Control Protocol/Internet Protocol (TCP/IP) stack.

The MIPAVapplication starts a DICOM image receiver that runs in the background and listens on a given port for incoming DICOM-store requests. When a store request is received by the DICOM receiver, the DICOM-formatted images are saved to the local system disk in the user-designated images directory. Once stored, you can use MIPAV to access, visualize, and analyze images.

MIPAV can also send selected images that are on the local disk to a remote destination by implementing the composite storage (C-STORE) service class as a service class user (SCU).

Finally, and most important, MIPAV has a query and retrieve capability that allows you to query a remote DICOM query server for patient, study, series, and image information. You can select from the responses to the query the set of images to be retrieved (moved) to the local disk for visualization and analysis.

Implementation model

This section describes the application entities (AEs) in the MIPAV DICOM communications interface and how they relate to both local and remote real-world activities. The implementation model consists of an application data flow diagram and functional definitions of all DICOM processes handled by the MIPAV AE.

The MIPAV DICOM receiver conforms to the DICOM standard as a service class provider (SCP) of most C-STORE service object pair (SOP) classes. The MIPAV query/retrieve process conforms to the DICOM standard as a SCU for DICOM C-FIND and C-MOVE services. In addition, the MIPAV DICOM sender conforms to the DICOM standard as a SCU for most DICOM C-STORE SOP classes.

Application data flow diagram

Figure 1 shows the relationship between the MIPAV AE and its DICOM processes and the remote AE and its DICOM processes. The remote AE could be any DICOM-compliant system that acts as a query/retrieve server and a DICOM image file receiver and sender, such as a DICOM image archive.

Figure 1. MIPAV dataflow diagram

Functional definitions of AEs

This section describes the image verification, query, and transfer functions to be performed by the MIPAV AE and the DICOM services used to accomplish these functions.

Verification

The MIPAV DICOM communications interface verifies application-level communication with a remote DICOM AE with the C-ECHO (Verification) SOP class in the SCP role. A remote DICOM AE supporting the Verification SOP class SCU role shall send a C-ECHO request to the MIPAV application. The MIPAV AE then sends a response of SUCCESS to confirm DICOM communications between the two AEs.

DICOM receiver (C-STORE SCP)

The DICOM image receiver is initialized as a standalone resident program when the MIPAV application is started. The DICOM receiver waits for a remote AE to request a connection at the presentation address configured for its AE Title. The presentation address of the DICOM receiver consists of the system IP address, AE Title, and communications port. The AE Title and communications port for the DICOM receiver are user configurable in the preferences file mipav.preferences.

The DICOM receiver accepts associations with Presentation Contexts for the SOP Classes of the Storage Service Class. Thus, the DICOM receiver accepts storage requests for Computed Tomography (CT), Magnetic Resonance (MR), Ultrasound (US), Nuclear Medicine (NM), Computed Radiography (CR), and most other modalities. It receives the images and writes them to files in the format specified in Digital Imaging and Communications In Medicine (DICOM) Part 10: Media Storage and File Format for Media Interchange (see Appendix E for a full citation.)

DICOM query (C-FIND SCU)

The MIPAV application supports the DICOM C-FIND query class as a SCU by allowing you to query a remote DICOM query server (C-FIND SCP) for patient, study, series, and image information. MIPAV employs the Study Root Query/Retrieve Information Model based on the three-level hierarchy:

Study-Study is the top level. It contains attributes associated with the study and patient information entity's (IE).

Series-The series level, which is below the study level, contains attributes associated with the series, frame of reference, and equipment IEs.

Image-Image is the lowest level. It contains attributes associated with the Image IE.

You can use a Study Root Study Level C-FIND request message, with search key attributes of patient name or patient ID and study date range, to query the SCP for a patient list or for demographic information about a given patient. A Study Root Study Level query, with a known search key attribute of patient ID, can be sent to the Query SCP for the study list corresponding to the given patient ID. Once the desired study is queried, then MIPAV can send a Study Root Series Level query with the known Unique Key Attributes of Patient ID and Study Instance UID to the query server for the list of series corresponding to the given study. Finally, once the desired series is located, you can query at the Study Root Image Level with known Key Attributes of Patient ID, Study Instance UID, and Series Instance UID to get the list of images corresponding to the selected series.

The MIPAV query routine interprets all PENDING status responses from the C-FIND SCP as matches to the key attributes in the query request. A status equal to SUCCESS, FAILED or REFUSED conveys the end of query request.

To cancel the C-FIND service, the MIPAV AE issues a C-FIND-CANCEL request at any time during the processing of the C-FIND query. The MIPAV query routine that issued the C-FIND request recognizes a status of CANCELED to indicate that the C-FIND-CANCEL was successful.

DICOM retrieve (C-MOVE SCU)

MIPAV supports the DICOM C-MOVE SOP class as a SCU. You can request the transfer of images from a remote AE to the local system or to a desired remote destination with a DICOM C-MOVE service request. The destination for the move, whether it is the local disk or a remote system, may be configured and selected from a host table from within the MIPAV DICOM Communication Panel window. The Move Destination is specified by the parameters of AE Title, IP Address, and Communications Port number in the Hosts table. To review or modify the configuration of the Hosts table, the user selects the Hosts tab from the DICOM Communication Panel window.

The DICOM C-MOVE class employs, like the DICOM Query, the Study Root Query/Retrieve Information Model based on the three-level hierarchy:

Study-A C-MOVE request at the study level transfers all images related to a study to the designated move destination.

Series-A C-MOVE request at the series level transfers all images related to a series.

Image-A C-MOVE request at the image level transfers all selected individual images.

The MIPAV retrieve routine supplies unique key values to identify an entity at the level of retrieval to the C-MOVE SCP. The SCP executes C-STORE suboperations for the corresponding storage SOP instances identified by the unique key values in the C-MOVE request. The MIPAV retrieve routine interprets all PENDING status responses from the C-MOVE SCP as matches to the key attributes in the retrieve request. A status equal to SUCCESS, FAILED, or REFUSED conveys the end of the retrieve request.

The MIPAV AE may cancel the C-MOVE service request by issuing a C-MOVE-CANCEL request at any time during the processing of the C-MOVE request. The MIPAV retrieve routine that issued the C-MOVE request recognizes a status of CANCELED to indicate that the C-MOVE-CANCEL was successful.

DICOM sender (C-STORE SCU)

MIPAV provides the DICOM C-STORE SOP class as a SCU.
To access the DICOM send option

1 Select File > DICOM Database Access in the MIPAV window. The DICOM Communication Panel window opens.

2 Select Send to view the Send page.

3 Select a patient, study, series, or image to send to a designated destination. The store destination is specified by the parameters of AE Title, IP Address, and Communications Port number in the hosts table.

To review or modify the configuration of the hosts table

1 Select Hosts in the DICOM Communication Panel window. The Hosts page opens.

2 Select the desired image data and the storage destination.

3 Click OK. The MIPAV sender routine establishes an association with the selected destination and transfers the image data.

Sequencing of real-world activities

Not applicable.

AE specifications

This section provides detailed specifications of the MIPAV DICOM communications interface. It lists the SOP classes supported and outlines the policies with which MIPAV initiates or accepts associations. A description of proposed (for association initiation) and acceptable (for association acceptance) Presentation contexts is also provided.

Note that a Presentation Context consists of an Abstract Syntax and a list of acceptable Transfer Syntaxes. The Abstract Syntax identifies one SOP Class or Meta SOP Class. By listing the AEs with their proposed and accepted Presentation Contexts, this Conformance Statement identifies the set of Information Objects and Service classes recognized by MIPAV.

For each SOP Class related to an Abstract Syntax, a list is given of any supported SOP options.

MIPAV AE specification

This section summarizes the SOP classes that are supported by the MIPAV DICOM Communications interface. The supported SOP classes are listed in two categories:

SOP classes supported by MIPAV as a SCU

SOP classes supported by MIPAV as a SCP

MIPAV provides Standard Conformance to the DICOM V3.0 SOP Classes shown in Table 1 as a SCU.

Table 1. DICOM query, retrieve, and sender classes supported by MIPAV

SOP class name	SOP class UID
DICOM query
Study Root Query/Retrieve Information Model, C-FIND	1.2.840.10008.5.1.4.1.2.2.1
DICOM retrieve
Study Root Query/Retrieve Information Model, C-MOVE	1.2.840.10008.5.1.4.1.2.2.2
DICOM sender
CR Image Storage	1.2.840.10008.5.1.4.1.1.1
CR Image Storage	1.2.840.10008.5.1.4.1.1.2
MR Image Storage	1.2.840.10008.5.1.4.1.1.4
NM Image Storage	1.2.840.10008.5.1.4.1.1.20
US Image Storage	1.2.840.10008.5.1.4.1.1.6
Secondary Capture Image Storage	1.2.840.10008.5.1.4.1.1.7

MIPAV provides Standard Conformance to the DICOM version 3.0 SOP Classes shown in Table 2 as a SCP.

Table 2. Verification and DICOM receiver classes supported by MIPAV

SOP class name	SOP class UID
Verification	Â
Verification SOP Class	1.2.840.10008.1.1
DICOM receiver
CR Image Storage	1.2.840.10008.5.1.4.1.1.1
CT Image Storage	1.2.840.10008.5.1.4.1.1.2
MR Image Storage	1.2.840.10008.5.1.4.1.1.4
NM Image Storage	1.2.840.10008.5.1.4.1.1.20
US Image Storage	1.2.840.10008.5.1.4.1.1.6

DICOM query (C-FIND SCU) AE specification

MIPAV provides standard conformance to the DICOM 3.0 Query/Retrieve SOP class listed in Table 3.

Table 3. Supported C-FIND SOP class

SOP class name	SOP class UID
Study Root Query/Retrieve Information Model C-FIND	1.2.840.10008.5.1.4.1.2.2.1

Association establishment policies

General

The MIPAV query routine initiates an association with a remote DICOM query server. Extended negotiation is not provided.

The maximum Protocol Data Unit (PDU) size in an association request defaults to 16 kilobytes.

Number of associations

Each query request within MIPAV initiates an association with a remote DICOM query server. Thus, multiple associations can be opened and processed by MIPAV in one working session.

Asynchronous nature

The DICOM Query routine only allows a single outstanding operation on an Association. Thus, there is no asynchronous activity in this implementation.

Implementation identifying information

(TBD. Need information on the Implementation Class Unique Identifier (UID) for the MIPAV query routine. Note that this may be the same for all applications, one implementation UID for a DICOM application. For information, contact Richard Eaton at NEMA at 703/841-3248 or e-mail at ric_eaton@nema.org).

Association initiation by real-world activity

To initiate an association from MIPAV to a remote query server (C-FIND SCU), select the Send Query button in the DICOM Communication Panel window.

Query request

After you insert the search keys and set the study date range in the DICOM Communication Panel window, you can then select the Send Query button to transfer the C-FIND request to the remote DICOM query server. Each query opens an association with the query server. Select Cancel at the bottom of the DICOM Communication Panel window to cancel the C-FIND request. The C-FIND-CANCEL request is sent over the same association as the originating C-FIND request.

Associated real-world activity

The initiation of a C-FIND request is the associated real-world activity.

Proposed Presentation Contexts

When MIPAV initiates a C-FIND request, a presentation context is proposed for the Study Root Query/Retrieve C-FIND supported SOP Class. No extended negotiation is supported.

Table 4. Presentation context proposed by MIPAV as a result of real-world activity query request to an external query server

Presentation context table
Abstract syntax		Transfer syntax		Role	Extended negotiation
Name	UID	Name list	UID list
Study Root Q/R C-FIND	1.2.840.10008.5.1.4.1.2.2.1	Implicit VR Little Endian	1.2.840.10008.1.2	SCU	None

SOP specific conformance statement for SOP class study root query/retrieve information model C-FIND

The attributes listed in Table 5 comprise the Study Root Query/Retrieve C-FIND identifier that is sent in the DICOM query message. The level column indicates the query level at which the attributes can be included.

Table 5. DICOM data elements supported for SOP class study root query/retrieve information model C-FIND SCU"

Level	Description	Tag	Type
Study
Study	Study Date	(0008,0020)	R
Study	Study Time	(0008,0030)	R
Study	Study ID	(0020,0010)	R
Study	Patient's Name	(0010,0010)	R
Study	Patient ID	(0010,0020)	R
Study	Study Instance UID	(0020,000D)	U
Study	Referring Physician's Name	(0008,0090)	O
Series
Series	Modality	(0008,0060)	R
Series	Series Number	(0020,0011)	R
Series	Series Instance UID	(0020,000E)	U
Series	Series Date	(0008,0021)	O
Series	Series Description	(0008,103E)	O
Series	Body Part Examined	(0018,0015)	O
Image
Image	Image Number	(0020,0013)	R
Image	SOP Instance UID	(0008,0018)	U
Image	Image Date	(0008,0023)	O
Image	Image Time	(0008,0033)	O

Association acceptance policy

Not applicable.

DICOM retrieve (C-MOVE SCU) AE specification

MIPAV provides standard conformance to the DICOM 3.0 Query/Retrieve SOP class.

Table 6. Supported image storage service

SOP class name	SOP class UID
Study Root Query/Retrieve Information Model C-MOVE	1.2.840.10008.5.1.4.1.2.2.2

Association establishment policies

General

The MIPAV retrieve routine initiates an association with a remote DICOM query/retrieve server. Extended negotiation is not provided.

The maximum PDU size in an association request defaults to 16 kilobytes.

Number of associations

Each retrieve (C-MOVE) request within the MIPAV application initiates an association with a remote DICOM query/retrieve server. Thus, multiple associations for the C-MOVE SOP class can be opened and processed by MIPAV in one working session.

Asynchronous nature

The DICOM Receiver only allows a single outstanding operation on an association. Thus, there is no asynchronous activity in this implementation.

Implementation identifying information

(TBD. Need the Implementation Class Unique Identifier (UID) for the MIPAV move request routine. Note that this may be the same for all applications-one implementation UID for a DICOM application. For information, contact Richard Eaton at NEMA at 703/841-3248 or e-mail at ric_eaton@nema.org.

Association initiation by real-world activity

To initiate an association from MIPAV to a remote query/retrieve server (C-MOVE SCP), select Q/R Client in the DICOM Communication Panel window. Then complete the appropriate parameters in the Q/R Client page. Initially run a query from the Q/R Client page. You can then select an entry from the query responses that indicates the desired patient, study, series, or image to be moved to the set destination. The destination to be moved to with the C-MOVE request is user configurable in the Hosts page, which is in the DICOM Query Panel window.

Retrieve request

After you successfully query the remote query/retrieve server and locate the set of images to move to the local system, you can then send a C-MOVE request to move the desired images to the local system. To initiate the C-MOVE request, click Move Image in the DICOM Communication Panel window, which then opens an association to the remote query/retrieve server. The remote server then responds to the C-MOVE request by initiating a C-STORE request on a new association to the C-STORE SCU process in the MIPAV application.

Associated real-world activity

The initiation of a C-MOVE request is the associated real-world activity.

Proposed presentation contexts

When MIPAV initiates a C-MOVE request, a presentation context is proposed for the Study Root Query/Retrieve C-MOVE supported SOP Class. No extended negotiation is supported.

Table 7. Presentation context proposed by MIPAV as a result of
real-world activity "MOVE Request to an External Query Server"

Presentation context table
Abstract syntax		Transfer syntax		Role	Extended negotiation
Name	UID	Name list	UID list
Study Root Q/R C-MOVE	1.2.840.10008.5.1.4.1.2.2.2	Implicit VR Little Endian	1.2.840.10008.1.2	SCU	1.2.840.10008.1.2

SOP specific conformance statement for SOP Class Study Root Query/Retrieve Information Model C-MOVE

The attributes listed in Table 8 comprise the Study Root Query/Retrieve C-MOVE identifier that is sent in the DICOM retrieve message. The level column indicates the query level at which the attributes can be included. Note that the table of attributes below is identical to those for the Study Root Query/Retrieve C-FIND identifier in Table 8]

Table 8. DICOM data elements supported for SOP Class Study Root Query/Retrieve Information Model C-MOVE SCU

Level	Description	Tag	Type
Study
Study	Study Date	(0008,0020)	R
Study	Study Time	(0008,0030)	R
Study	Study ID	(0020,0010)	R
Study	Patient's Name	(0010,0010)	R
Study	Patient ID	(0010,0020)	R
Study	Study Instance UID	(0020,000D)	U
Study	Referring Physician's Name	(0008,0090)	O
Series
Series	Modality	(0008,0060)	R
Series	Series Number	(0020,0011)	R
Series	Series Instance UID	(0020,000E)	U
Series	Series Date	(0008,0021)	O
Series	Series Description	(0008,103E)	O
Series	Body Part Examined	(0018,0015)	O
Image
Image	Image Number	(0020,0013)	R
Image	SOP Instance UID	(0008,0018)	U
Image	Image Date	(0008,0023)	O
Image	Image Time	(0008,0033)	O

Association acceptance policy

Not applicable.

DICOM sender (storage SCU) AE specification

MIPAV provides standard conformance to the DICOM 3.0 Storage SOP classes listed in Table 9

Table 9. Supported C-STORE SOP classes

SOP class name	SOP class UID
Computed Radiography Image Storage	1.2.840.10008.5.1.4.1.1.1
CT Image Storage	1.2.840.10008.5.1.4.1.1.2
MR Image Storage	1.2.840.10008.5.1.4.1.1.4
Nuclear Medicine Image Storage	1.2.840.10008.5.1.4.1.1.20
Ultrasound Image Storage	1.2.840.10008.5.1.4.1.1.6
Secondary Capture Image Storage	1.2.840.10008.5.1.4.1.1.7

Association establishment policies

General

The MIPAV DICOM image sender initiates an association with a remote DICOM image receiver. Extended negotiation is not supported.

The maximum PDU size in an association request defaults to 16 kilobytes.

Number of associations

Each send (C-STORE) request within the MIPAV application initiates an association with a remote DICOM image receiver. Thus, multiple associations for the C-STORE SOP class can be opened and processed by MIPAV in one working session.

Asynchronous nature

The DICOM Sender only allows a single outstanding operation on an Association. Thus, there is no asynchronous activity in this implementation.

Implementation identifying information

(TBD. Need the Implementation Class Unique Identifier (UID) for the MIPAV DICOM Sender. Note that this may be the same for all applications- one implementation UID for a DICOM application. For information, contact Richard Eaton at NEMA at 703/841-3248 or through e-mail at ric_eaton@nema.org.

Association initiation by real-world activity

To initiate an association from MIPAV to a remote image receiver (C-STORE SCP), select Send in the DICOM Query Panel window. When you select File > DICOM Database Access in the MIPAV window, the DICOM Communication Panel window opens.

DICOM send request

Associated real-world activity

The initiation of a Send image request is the associated real-world activity.

Proposed presentation contexts

When MIPAV initiates a C-STORE request, a different presentation context is proposed for each of the different supported C-STORE SOP Classes. No extended negotiation is supported.

Table 10. Presentation contexts proposed by MIPAV as a result of real-world activity "store request to an external query server

Presentation context table
Abstract syntax		Transfer syntax		Role	Extended negotiation
Name	UID	Name list	UID list
CR Image Storage	1.2.840.10008.5.1.4.1.1.1	Implicit VR Little Endian	1.2.840.10008.1.2	SCU	None
CT Image Storage	1.2.840.10008.5.1.4.1.1.2	Implicit VR Little Endian	1.2.840.10008.1.2	SCU	None
MR Image Storage	1.2.840.10008.5.1.4.1.1.4	Implicit VR Little Endian	1.2.840.10008.1.2	SCU	None
US Image Storage	1.2.840.10008.5.1.4.1.1.6	Implicit VR Little Endian	1.2.840.10008.1.2	SCU	None
Secondary Capture Image Storage	1.2.840.10008.5.1.4.1.1.7	Implicit VR Little Endian	1.2.840.10008.1.2	SCU	None

SOP specific conformance statement for supported storage SOP classes

The following overview summarizes the behavior of the MIPAV DICOM Sender routine depending on the responses to the C-STORE request:

Successful C-STORE response: In the case of a response of SUCCESS for the C-STORE request, the MIPAV Send status panel in the Send page in the DICOM Communication Panel window displays a status of SUCCESS. This indicates that the images were properly received by the image receiver (C-STORE SCU).

Unsuccessful C-STORE response: In the case of a response of REFUSED, CANCEL, or FAILED, for the C-STORE request, the DICOM sender routine aborts the association. The MIPAV Send status panel in the Send page in the DICOM Communication Panel window displays a status of FAILED. The software makes no further attempts to retry the transfer of the aborted images.

Warning status in C-STORE response: In the case of a response of Warning for the C-STORE request, the MIPAV DICOM sender routine behaves the same as if a response of SUCCESS was received.

The DICOM Sender does not attempt any extended negotiation.

The DICOM Sender supports all type 1, type 2, and type 3 attributes defined in the Information Object Definition (IOD) associated with the SOP class. No attributes are discarded or coerced by the DICOM Sender. The originally saved DICOM file is read from disk and forwarded to the desired remote system. Note that the DICOM Sender does not validate that the attributes of the SOP instance for the outgoing C-STORE message request meet the requirements of the IOD. It is assumed that the saved DICOM image file is stored in a valid DICOM file format.

The SOP Instance UID (group 0x0008, element 0x0018), Study Instance UID (group 0x0020, element 0x000D), and Series Instance UID (group 0x0020, element 0x000E) consist of a root and suffix. The root consists of the date and time of transaction. The suffix is conforms to the DICOM standard.

Association acceptance policy

Not applicable.

Verification (C-Echo SCP) AE specification

MIPAV provides standard conformance to the DICOM 3.0 Verification SOP class listed in Table 11].

Table 11. Supported verification SOP class

SOP class name	SOP class UID
Verification SOP Class	1.2.840.10008.1.1

Association establishment policies

General

The MIPAV DICOM Verification routine responds to a verification of communication request from a remote DICOM AE by sending a C-Echo response of a status of SUCCESS.

The maximum PDU size in an association request defaults to 16 kilobytes.

Number of associations

Each verification (C-Echo) request sent to the MIPAV application is responded to on an association opened by the remote AE. Multiple associations for the C-ECHO SOP class can be accepted and processed by MIPAV in one working session.

Asynchronous nature

The DICOM verification routine only allows a single outstanding operation on an Association. Thus, there is no asynchronous activity in this implementation.

Implementation Identifying Information

(TBD. Need the Implementation Class Unique Identifier (UID) for the MIPAV DICOM verification routine. Note that this may be the same for all applications- one implementation UID for a DICOM application. For information contact Richard Eaton at NEMA- (703) 841-3248, email- ric_eaton@nema.org)

Association initiation by real-world activity

Not applicable.

Association Acceptance Policy

MIPAV accepts all associations for C-ECHO requests initiated by remote systems.

DICOM Verification Request

Associated Real-World Activity

The arrival of a verification, or C-Echo, request is the associated real-world activity.

Proposed Presentation Contexts

When the MIPAV Message Receiver gets a verification request, the presentation context accepted for the C-ECHO SOP class is listed in Table 12. No extended negotiation is supported.

Table 12. Presentation contexts accepted by MIPAV as a result of real-world activity "verification" request

Presentation context table
Abstract syntax		Transfer syntax		Role	Extended negotiation
Name	UID	Name list	UID list
Verification	1.2.840.10008.5.1.4.1.1.1	Implicit VR Little Endian	1.2.840.10008.1.1	SCP	None

SOP Specific Conformance Statement for Verification SOP Class

The Verification AE follows the DICOM 3.0 standard for handling of C-ECHO requests. A status of SUCCESS is returned to a valid C-ECHO verification request.

DICOM image receiver (storage SCP) AE specification

MIPAV provides standard conformance to the DICOM 3.0 Storage SOP classes listed in Table 13

Table 13. Supported C-STORE SOP classes

SOP class name	SOP class UID
CR Image Storage	1.2.840.10008.5.1.4.1.1.1
CT Image Storage	1.2.840.10008.5.1.4.1.1.2
MR Image Storage	1.2.840.10008.5.1.4.1.1.4
NM Image Storage	1.2.840.10008.5.1.4.1.1.20
US Image Storage	1.2.840.10008.5.1.4.1.1.6
Secondary Capture Image Storage	1.2.840.10008.5.1.4.1.1.7

Association Establishment Policies

General

The MIPAV DICOM image receiver opens a node at the port specified in the mipav.preferences file and waits for an association from a DICOM application at the specified port. MIPAV accepts an association from a remote DICOM image sender. Extended negotiation is not supported.

The maximum PDU size in an association request defaults to 16 kilobytes.

Number of Associations

The DICOM Image Receiver initiates a new process for each connection request it receives. Thus, the image receiver can have multiple simultaneous connections and there are no inherent limitations on the total number of simultaneous associations that the image receiver can maintain.

Asynchronous Nature

The DICOM Image Receiver only allows a single outstanding operation on an Association. Thus, there is no asynchronous activity in this implementation.

Implementation Identifying Information

(TBD. Need the Implementation Class Unique Identifier (UID) for the MIPAV DICOM Receiver. Note that this may be the same for all applications- one implementation UID for a DICOM application. For information contact Richard Eaton at NEMA- (703) 841-3248, email- ric_eaton@nema.org)

Association Initiation by Real-World Activity

Not applicable. The DICOM Image Receiver never initiates an association.

Association Acceptance Policy

When the MIPAV Image Receiver accepts an association, it receives any images transferred on that association and stores the images on the local disk in the native machine file system, in the format specified in Digital Imaging and Communications In Medicine (DICOM) Part 10: Media Storage and File Format for Media Interchange (see Appendix E for a full citation.) The Image Receiver places no limitation on who may connect to it, or the number of simultaneous connections it can support.

DICOM image receiver

Associated real-world activity

The storage of an image on the disk of the local system is the associated real-world activity for the Image Receiver.

Proposed presentation contexts

The presentation contexts accepted by the MIPAV Image Receiver are listed in Table 14. No extended negotiation is supported.

Table 14. Presentation contexts proposed by MIPAV as a result of real-world activity "receive and store images"

Presentation context table
Abstract syntax		Transfer syntax		Role	Extended negotiation
Name	UID	Name list	UID list
CR Image Storage	1.2.840.10008.5.1.4.1.1.1		Implicit VR Little Endian		1.2.840.10008.1.2
CT Image Storage	1.2.840.10008.5.1.4.1.1.2		Implicit VR Little Endian		1.2.840.10008.1.2
MR Image Storage	1.2.840.10008.5.1.4.1.1.4		Implicit VR Little Endian		1.2.840.10008.1.2
NM Image Storage	1.2.840.10008.5.1.4.1.1.20		Implicit VR Little Endian		1.2.840.10008.1.2
US Image Storage	1.2.840.10008.5.1.4.1.1.6		Implicit VR Little Endian		1.2.840.10008.1.2
Secondary Capture Image Storage	1.2.840.10008.5.1.4.1.1.7		Implicit VR Little Endian		1.2.840.10008.1.2

SOP Specific Conformance Statement for Supported Storage SOP Classes

The MIPAV Image Receiver conforms to the Storage SOP Classes as a SCP at Level 2 (Full). No elements are discarded or coerced by the MIPAV Image Receiver. In the event of a successful C-STORE operation, the DICOM image file is successfully written to the local disk with a standard path and file name format. The default path for the image data is /images. The default path can be customized in the mipav.preferences file. The image receiver does not support any extended negotiation.

Communications profiles

Overview

This section lists all communication protocols supported by MIPAV.

Supported communications stacks

TCP/IP

The MIPAV DICOM routines run over the TCP/IP stack.

Application Programmer's Interface (API)

The MIPAV DICOM routines are implemented using the Berkeley Sockets interface to TCP/IP services.

Physical Media Supported

The MIPAV DICOM routines run on any physical media supported by the TCP/IP stack that is run on the host machine.

Extensions, Specializations, and Privatizations

Overview

This section lists all DICOM Standard extended, specialized, or private SOP Class implementations.

MIPAV AE DICOM Services

No extended, specialized, or private SOPs are specified.

DICOM Configuration Details

Overview

This section addresses the method of setting configurable parameters for the DICOM routines.

For the MIPAV DICOM Receiver, the port number and AE Title are configurable in the mipav.preferences file.

The MIPAV Query/Retrieve process also uses the AE Title, IP Address, and port number settings for the host machine and the remote query server. You can change the values for these settings on the Hosts page in the DICOM Communication Panel window. The settings can also be configured in the mipav.preferences file.

AE Title/Presentation Mapping

The MIPAV DICOM routines map the AE title to a presentation address (IP address and port number) by accessing information on the Hosts page in the DICOM Communication Panel window. This is then written and saved in the mipav.preferences file.

Support of Extended Character Sets

Overview

Any support for extended character sets, such as multibyte characters, are described in this section.

MIPAV ICOM AE

MIPAV does not support extended character sets.

Table 15. DICOM tags

Field	Description
Study Instance UID (0020,000D)	Unique identifier for the study. Only numeric characters with optional periods are allowed.
Modality (0008,0060)	Type of equipment that was used to acquire the data used to create the images in the dataset. Options are: Biomagnetic Imaging, Color Flow Doppler, Computed Tomography, Duplex Doppler, Computed Radiography, Diaphanography, Digital Radiography, Endoscopy, General Microscopy, Hard Copy, Intraoral Radiography, Laser Surface Scan, MR Angiography, Mammography, Magnetic Resonance, MR Spectroscopy, Nuclear Medicine, Other, PET, Panoramic XRay, Radio Fluoroscopy, Radiographic Imaging, Radiotherapy Dose, Radiotherapy Image, Radiotherapy Record, Radiotherapy Structure, Slide Microscopy, SPECT, Thermography, Ultrasound, XRay Angiography, and External Photography.
Series Instance UID (0020,000E)	Unique identifier for the study. Only numeric characters (with optional periods) are allowed.
Patient
Patient's Name (0010,0010)	Patient's full name.
Patient's Birth Date (0010,0030)	Date of patient's birth.
Patient's Birth Time (0010,0032)	Time of patient's birth.
Other Patient Names (0010,1001)	Other names used to identify the patient.
Patient Comments (0010,4000)	User-defined comments about the patient.
Patient ID (0010,0020)	Primary hospital identification number or code used to identify the patient.
Patient's Sex (0010,0040)	Gender of the patient. Options are: Unknown, Male, Female, and Other.
Other Patient IDs (0010,1000)	Other IDs used to identify the patient.
Ethnic Group (0010,2160)	Ethnic group or race of the patient.
Patient Orientation (0020,0020)	Patient direction of the rows and columns of the image.
Study
Study ID (0020,0010)	User- or equipment-generated study identifier.
Study Time (0008,0030)	Time the study started.
Study Description (0008,1030)	Institute-generated description or classification of the study (component) performed.
Physician(s) of Record (0008,1048)	Physician responsible for the overall patient care at the time of the study.
Admitting Diagnoses Description (0008,1080)	Description of the admitting diagnoses.
Patient's Size (0010,1020)	Length or size of the patient in meters.
Occupation (0010,2180)	Occupation of the patient.
Study Date (0008,0020)	Date the study started.
Accession Number (0008,0050)	An RIS-generated number which identifies the order for the study.
Referring Physician's Name (0008,0090)	Patient's referring physician.
Physician(s) Reading Study (0008,1060)	Physician(s) reading the study.
Patient's Age (0010,1010)	Age of the patient.
Patient's Weight (0010,1030)	Weight of the patient, in kilograms.
Additional Patient's History (0010,21B0)	Additional information about the patient's history.
Series
Series Number (0020,0011)	A number that identifies this series.
Performing Physicians' Name (0008,1050)	Name(s) of the physician(s) administering the series.
Series Description (0008,103E)	User-provided description for the series.
Body Part Examined (00018,0015)	A text description of the body part that was examined. Options are: Unknown, Skull, CSpine, TSpine, LSpine, SSpine, Coccyx, Chest, Clavicle, Breast, Abdomen, Pelvis, Hip, Shoulder, Elbow, Knee, Ankle, Hand, Foot, Extremity, Head, Heart, Neck, Leg, Arm, and Jaw.
Smallest Pixel Value (0028,0108)	Minimum value of all images in this series.
Procedure Step ID (0040,0253)	Identification of that part of a procedures that was performed during this step.
Procedure Step Start Time (0040,0245)	Time when the procedure step started.
Laterality (0020,0080)	Options are: Unknown, Left, and Right.
Series Time (0008,0031)	Time series started.
Protocol Name (0018,1030)	User-defined description of the conditions under which the series was performed.
Operator's Name (0008,1070)	Name(s) of the technologist(s) supporting the series.
Patient Position (0018,5100)	Patient position relative to the imaging-equipment space. Options are: Unknown, Head-First Prone, Head-First Supine, Feet First-Prone, Feet First-Supine, HF-Decubitus Right, HF-Decubitus Left, FF-Decubitus Right, FF-Decubitus Left.
Largest Pixel Value (0028,0109)	Maximum value of all images in this series.
Procedure Step Start Date (0040,0244)	Date when the procedure step started.
Procedure Step Description (0040,0254)	Institute-generated description or classification of the procedure step that was performed.