dysect DICOM Conformance Statement 1
dysect DICOM Conformance Statement (041-00-0007 H) dysect Conformance Statement.doc DeJarnette Research Systems, Inc. 401 Washington Avenue, Suite 1010 Towson, Maryland 21204 Copyright 2004-2008 This document and the associated software are copyrighted by DeJarnette Research Systems, Inc. of Towson, Maryland. Neither this document nor the associated software may be reproduced or copied without the expressed written consent of DeJarnette Research Systems, Inc. This document may include technical inaccuracies and/or typographical errors. Changes are periodically made to the information herein and incorporated into new editions of the document. DeJarnette Research Systems may make improvements and/or changes to the product(s) and/or the program(s) described in this document at any time. This document may contain reference to or information about DeJarnette Research Systems products (hardware or software) or services that are not available in all countries. Such references or information do not imply any intent on DeJarnette s part to make such products or services available to these locations. DeJarnette and dysect are trademarks or registered trademarks of DeJarnette Research Systems, Inc. DICOM is the registered trademark of the National Electrical Manufacturers Association for its standards publications relating to digital communications of medical information. Other product names mentioned in this document may be registered trademarks of their respective companies and are hereby acknowledged. Revision Table Rev Date Comments A 13 January 2004 Document created for dysect Release V1.0 B 08 June 2004 Minor functional changes made during beta testing phase. C 24 February 2005 Document updated for dysect Release V2.0 D 23 March 2005 Document updated for dysect Release V2.0 build 6 E 1 December 2006 Document updated for dysect Release V3.0 (name change) F 24 May 2007 Document updated for dysect Release V3.0.1 G 6 May 2008 Document updated for dysect Release V4.0 H 27 August 2008 Document updated for dysect Release V4.0.1 2
Table of Contents 1 INTRODUCTION...6 2 IMPLEMENTATION MODEL...6 2.1 APPLICATION DATA FLOW DIAGRAM...6 2.2 FUNCTIONAL DEFINITIONS OF AES...7 2.3 SEQUENCING OF REAL-WORLD ACTIVITIES...8 3 AE SPECIFICATIONS...9 3.1 AE SPECIFICATION - STOREP AE...9 3.1.1 Association Establishment Policies...9 3.1.1.1 General... 9 3.1.1.2 Number of Associations... 9 3.1.1.3 Asynchronous Nature... 9 3.1.1.4 Implementation Identifying Information... 9 3.1.2 Association Initiation Policy...10 3.1.3 Association Acceptance Policy...10 3.1.3.1 Real-World Activity... 10 3.1.3.1.1 Associated Real-World Activity... 10 3.1.3.1.2 Proposed Presentation Contexts... 10 3.1.3.1.3 SOP Specific Conformance for Verification SOP Classes... 11 3.1.3.1.4 Presentation Context Acceptance Criterion... 15 3.1.3.1.5 Transfer Syntax Selection Policies... 15 3.2 AE SPECIFICATION STOREU AE...16 3.2.1 Association Establishment Policies...16 3.2.1.1 General... 16 3.2.1.2 Number of Associations... 16 3.2.1.3 Asynchronous Nature... 16 3.2.1.4 Implementation Identifying Information... 16 3.2.2 Association Initiation Policy...17 3.2.2.1 Associated Real-World Activity... 17 3.2.2.2 Presentation Context Table... 17 3.2.2.3 SOP Specific Conformance for all Storage Service SOP Classes...17 3.2.2.4 Association Acceptance Policy... 18 3.3 AE SPECIFICATION - MODALITY WORKLIST USER (MWLU)...19 3.3.1 Association Establishment Policies...19 3.3.1.1 General... 19 3.3.1.2 Number of Associations... 19 3.3.1.3 Asynchronous Nature... 19 3.3.1.4 Implementation Identifying Information... 19 3.3.2 Association Initiation Policy...19 3.3.2.1 Real-World Activity... 19 3.3.2.1.1 Associated Real-World Activity... 19 3.3.2.1.2 Proposed Presentation Contexts... 19 3.3.3 Association Acceptance Policy...21 3.4 AE SPECIFICATION MODALITY WORKLIST PROVIDER (MWLP)...22 3.4.1 Association Establishment Policies...22 3.4.1.1 General... 22 3.4.1.2 Number of Associations... 22 3.4.1.3 Asynchronous Nature... 22 3.4.1.4 Implementation Identifying Information... 22 3.4.2 Association Initiation Policy...22 3.4.3 Association Acceptance Policy...23 3
3.4.3.1 Fulfilling Queries... 23 3.4.3.1.2 Presentation Context Table... 23 3.4.3.1.3 Presentation Context Acceptance Criterion... 26 3.4.3.1.4 Transfer Syntax Selection Policies... 26 3.5 AE SPECIFICATION STORAGE COMMIT USER (SCOMMITU)...27 3.5.1 Association Establishment Policies...27 3.5.1.1 General... 27 3.5.1.2 Number of Associations... 27 3.5.1.3 Asynchronous Nature... 27 3.5.1.4 Implementation Identifying Information... 27 3.5.2 Association Initiation Policy...27 3.5.2.1 Real-World Activity... 27 3.5.2.1.1 Associated Real-World Activity... 27 3.5.2.1.2 Proposed Presentation Contexts... 28 3.5.3 Association Acceptance Policy...29 4 COMMUNICATION PROFILES...30 4.1 SUPPORTED COMMUNICATION STACKS...30 4.2 TCP/IP STACK...30 4.2.1 Physical Media...30 4.3 PROPRIETARY STACKS...30 5 EXTENSIONS / SPECIALIZATIONS / PRIVATIZATIONS...30 5.1 CONFIGURABLE REFERENCED STUDY SEQUENCE...30 6 CONFIGURATION...31 7 SUPPORT OF EXTENDED CHARACTER SETS...31 4
List of Figures Figure 2.1-1: Application Data Flow...7 List of Tables Table 3-1: Store Provider Supported Default SOP classes...9 Table 3-2 Store Provider Presentation Context Table...11 Table 3-3: Storage Response Codes...12 Table 3.1-4: dysect Storage Commitment Request...13 Table 3.1-5 dysect Storage Commitment Result Success (Event type=1)...13 Table 3.1-6: dysect Storage Commitment Result Failures Exist (Event type=2)...14 Table 3.1-7: dysect Storage Commitment Failure Codes...14 Table 3-8: Default SOP Classes supported by the Store AE...16 Table 3-9 Modified DICOM Header Attributes Table...18 Table 3-10: Presentation Context Table...20 Table 3-11: Requested Attribute Table...21 Table 3-12: Modality Work List SCP AE Supported SOP Classes...22 Table 3-13: Presentation Context Table...23 Table 3-14: Supported Attribute Table...25 Table 3-15: Type 2 Attribute Table...26 Table 3-16: Presentation Context Table...28 Table 3-17: dysect Storage Commitment Request...28 Table 3-18: dysect Storage Commitment Result Success (Event type=1)...29 Table 3-19: dysect Storage Commitment Result Failures exist (Event type=2)...29 Table 5-1: Attributes modified in the Standard Storage SOP Classes...30 5
1 INTRODUCTION The DeJarnette dysect is a gateway between a multi-slice CT scanner and a PACS. It receives DICOM Modality Worklist orders from the PACS and provides DICOM Modality Worklist orders to the CT scanner. It also receives DICOM C-STORE Storage requests from the CT scanner and sends DICOM C-STORE Storage requests to the PACS. When it receives orders from the PACS it shall identify orders that belong in the same study, create one super order and provide that order to the CT scanner. Orders that don t match any other order shall be presented to the CT scanner exactly as they are received from the PACS. The end result is that the CT scanner will see the same exact worklist that it would see if the dysect was not present, with the exception of studies with multiple orders that will be performed in a single scan. When the dysect receives studies from the CT scanner it will identify studies that match the super orders and attempt to identify the individual anatomical regions by processing the images. Upon successful identification of the anatomical regions it shall create a separate study for each and associate them with the correct order previously received from the PACS. It shall then send the separated studies to the PACS. Studies that don t match a super order will be forwarded to the PACS unaltered. This document specifies the dysect 's DICOM conformance. 2 IMPLEMENTATION MODEL The dysect is a gateway that can receive DICOM Modality worklist orders, and provide an altered worklist to a CT scanner. It can then receive studies from the scanner, automatically separate them into their proper anatomical regions and forward them to the PACS. Most orders and studies are passed through dysect unaltered. The orders that should be merged and consequently the studies that should be separated are configurable. 2.1 Application Data Flow Diagram A dysect acts as a gateway between a PACS and a CT scanner. It queries a PACS for DICOM Worklist orders and determines which orders should be combined to make one super order and which orders should be passed through unaltered. The dysect will only query the worklist for CT orders. It can be configured to determine which procedure codes should be grouped into one super order. It can also be configured to automatically group orders based on procedure code descriptions. Worklist orders that have the same patient ID and scheduled start time are grouped together. dysect provides the altered worklist to the CT scanner. After the study has been completed it is sent back to dysect. dysect will either pass the study though unaltered or separate the study and assign the proper images to the proper order based on anatomical regions. dysect uses information from the super orders to determine if the study should be separated. It will first check to see if the Study UID of the incoming study matches the Study UID of a super order in the database. If not then it will compare both the accession number and the patient ID of the incoming study to the orders in the database. If it finds a match then it will separate the study. dysect will forward the study to the PACS after it is processed. The dysect can also optionally act as a Storage Commit gateway. It will accept commit requests from a scanner and forward the requests onto the PACS. It will then pass the PACS response back to the scanner. If a commit request is for a study that was separated by dysect, then dysect will verify that all of the images created from a single image are committed before it returns a successful commit response to the scanner. Figure 2.1-1 illustrates the activity of the dysect DICOM AE entities. The workflow of the AE entities is indicated numerically 1-6, first receiving orders from the PACS, then interfacing with the scanner, then sending the studies 6
back to PACS. Finally, dysect can optionally be configured to pass through Storage Commit to transfer ownership. The dysect can also be configured to act as a VOI LUT gateway for the CT scanner. In this mode dysect can be configured to pass all DICOM Worklist orders to the scanner unaltered. dysect will then update the window width and center values for every study that it passes from the scanner to the PACS. The new window width and center values can be configured per procedure code. Pass Unaltered Orders (1) Single Orders Orders (2) MWLU AE Merge Super Orders MWLP AE Query for Worklist PACS Studies (4) Ownership (6) DICOM Standard Interface StoreU AE SCommitU AE Separate Studies Pass Unaltered Studies Dysect StoreP AE SCommit Studies (3) Ownership (5) DICOM Standard Interface Perform Scan Send Study Scanner Figure 2.1-1: Application Data Flow The dysect is designed to serve a single CT scanner at a time. dysect does not need operator intervention after the system is configured properly. However, a web based validation GUI can be used to verify and modify separated studies. Figure 2.1-1 does not detail Verification as an individual Real-World activity, however all SCP AEs (Store/ Storage Commitment and Worklist Management) on dysect have the Verification SCP incorporated. The dysect configuration files and database records contain all the supported destinations and settings. Refer to the dysect System Manual for information on configuration. 2.2 Functional Definitions of AEs The dysect has four DICOM Application Entities (AEs). Each SCP AE has the verification SCP embedded. 1. The first AE is the Storage Provider (StoreP) and Storage Commitment Server (SCS). The StoreP SCP temporarily stores the successfully received object, processes the message and if the processing is successful returns a success status to the sender. This AE uses a configurable timeout to wait for the closing of the association. Within that time range it is the courtesy of the caller to close the open association. The StoreP AE also includes a Storage Commitment (SCommit) SCP waiting for SCommit requests. Upon successful message reception the SCommit AE parses and interprets the request. It then forwards the 7
appropriate request(s) to the PACS and waits for a response. After a response is received from PACS a response message is generated with a list of all committed items. The response message is transmitted to the scanner using reverse role negotiation to establish a new association. If Storage Commit is not configured for PACS then a commit failed message is sent back to the scanner for all requests. This AE uses information from the registry to establish a TCP/IP connection and to negotiate a DICOM association. This AE forces the default transfer syntax on the sender unless configuration options are set otherwise. 2. The second AE is the Storage User (StoreU). The StoreU AE is used to move images to one of two destinations after processing the images. 3. The third AE is the Modality Worklist User (MWLU). It performs queries on a DICOM Worklist management server. This AE uses the information in the configuration file to establish a TCP/IP connection and a DICOM association. 4. The fourth AE is the Modality Worklist Provider (MWLP). The MWLP AE, upon a DICOM WLM SCU request performs queries on a local database and returns all new SPS (Scheduled Procedure Step) entries as Worklist items. This AE uses configuration information settings to establish a TCP/IP connection and to negotiate a DICOM association. 5. The fifth AE issues a Storage Commitment (SC) request to a configured PACS destination AE upon reception of a request from the scanner. After the request message is formatted and transmitted, a queue item (internal to the dysect) is set up to correlate the SC Response. The response is expected from the destination AE via another association. After the response is received it is saved in the local database and a response is sent back to the scanner. This AE uses the information in the registry to establish a TCP/IP connection and a DICOM association. 2.3 Sequencing of Real-World Activities There are three precedence issues in terms of dysect AEs. The dysect must query the DICOM Modality Worklist Provider (PACS) at least twice before it can provide DICOM Modality Worklist orders to the CT scanner. If the CT scanner queries dysect before this, then dysect will not return any worklist items. The information in the DICOM image header must match the information in a super order for dysect to attempt to separate the study. Typically the CT scanner will update the DICOM Header of all the images in a study with the necessary information in the Modality Worklist order provided by dysect. Storage commitment cannot be done for an item before it is received by the store provider. The dysect must successfully transfer an image before it sends a storage commitment request 8
3 AE SPECIFICATIONS 3.1 AE Specification - StoreP AE The dysect can only be configured with one StoreP AE Title. The StoreP AE provides conformance to the following DICOM SOP classes as a SCP: SOP Class Name SOP Class UID Verification 1.2.840.10008.1.1 Computed Tomography Image Storage (CT) 1.2.840.10008.5.1.4.1.1.2 Storage Commitment 1.2.840.10008.1.20.1 Table 3-1: Store Provider Supported Default SOP classes 3.1.1 Association Establishment Policies Associations can be accepted by the StoreP AE any time after the dysect has initialized the Storage Provider application. An association is accepted if resources are available, the called AE Title matches the dysect s StoreP AE Title, the application context is 1.2.840.10008.3.1.1.1, and at least one presentation context exists in the association request that matches one of the presentation contexts defined in the presentation context table. The default maximum PDU size supported for DICOM associations is 4,096 bytes. It can be changed during system configuration. 3.1.1.1 General The presentation context that is offered by the StoreP AE is the DICOM default. 3.1.1.2 Number of Associations The number of simultaneous associations a StoreP AE can accept is 32. However, only one StoreP AE can exist in the dysect. Also, the dysect should be set up to receive images from only one source. The dysect will accept connections from multiple sources, but performance will diminish considerably and the separation algorithm will fail. 3.1.1.3 Asynchronous Nature Not applicable. 3.1.1.4 Implementation Identifying Information The implementation UID supplied for DICOM associations is 2.16.840.1.113664.3.42.2. There is no implementation version name. 9
3.1.2 Association Initiation Policy The StoreP AE does not initiate any association as an SCP. An exception is the N-EVENT-REPORT message response for a Storage Commitment request where the StoreP AE remains an SCP and the association is initiated using reverse role negotiation. 3.1.3 Association Acceptance Policy The StoreP AE accepts an association if the proposed presentation context is found in its local presentation context table, if the targeted AE title is the StoreP AE and if the application context is 1.2.840.10008.3.1.1.1. The StoreP AE can be configured per Abstract Syntax to accept other then the default transfer syntax as well, however at this point the application level acceptance of the data is not guaranteed. A C-STORE association request can be rejected if there is not sufficient storage space on dysect to store a configurable size of message. The default required free space is 100 MB. 3.1.3.1 Real-World Activity The basic form of real-world activity is CT image data reception, store and forward with storage commitment (ownership confirmation) forwarding. 3.1.3.1.1 Associated Real-World Activity The associated real-world activities that occur after successful reception of image data is processing of DICOM header and image data and forwarding the data to one of three possible sources (PACS Primary, PACS Failover, or QC). The DICOM Header of the images may be altered if one of two conditions is met. One possible condition is if the image is part of a study that has been identified as a candidate for separation. If that study is successfully separated then the image UIDs, series UIDs, study UIDs, and several other elements in the DICOM header will be altered. The other possible condition is if the enable window and level configuration option is set. In that case the window width and window center values of the header will be updated with a configured window width and center value. For a complete list of the attributes that might be altered see Table 3-9 Modified DICOM Header Attributes Table. The study may be optionally held for validation or optionally routed to a configured QC destination. The criteria to determine if a study is to be held or sent to the QC destination is configurable by using the Validation GUI. Otherwise the study will be routed to a PACS destination. 3.1.3.1.2 Proposed Presentation Contexts The default DICOM presentation context is always accepted by the StoreP AE. By default only the DICOM Implicit VR, little-endian transfer syntax is accepted. The Big Endian Transfer Syntax presentation contexts can be added. The values specified in the base configuration correspond to the entries in Table 3-2. dysect configuration settings provide the facility to add other presentation contexts. All the presentation contexts defined will be offered, and the first one accepted will be used to transmit the message. 10
Abstract Syntax Transfer Syntax Role Extended Name UID Name List UID List Negotiation Verification 1.2.840.10008.1.1 DICOM Implicit VR Little Endian Computed Tomography (CT) Image Storage Storage Commitment Push Model 1.2.840.10008.5.1.4.1.1.2 DICOM Implicit VR Little Endian DICOM Explicit VR Little Endian DICOM Explicit VR Big Endian 1.2.840.10008.1.20.1 DICOM Implicit VR Little Endian Table 3-2 Store Provider Presentation Context Table 1.2.840.10008.1.2 SCP None 1.2.840.10008.1.2 SCP None 1.2.840.10008.1.2.1 SCP None 1.2.840.10008.1.2.2 SCP None 1.2.840.10008.1.2 SCP None 3.1.3.1.3 SOP Specific Conformance for Verification SOP Classes The StoreP AE provides standard conformance for the Verification SOP Class as an SCP. 3.1.3.1.3.1 SOP Specific Conformance for All Supported Image Storage SOP Classes The dysect provides Level 2 (full) conformance as an SCP of the Storage SOP Classes. All received Attributes are stored and may be subsequently accessed, including Private and other Type 3 Attributes that exist in Standard Extended SOP Instances. The DICOM Header of the images might be altered if one of two conditions is met. One possible condition is if the image is part of a study that has been identified as a candidate for separation and that study is successfully separated. The other possibility is if the enable window and level configuration option is turned on. All of the attributes that could be altered are listed in Table 3-9 Modified DICOM Header Attributes Table with the criteria for which they will be modified. The dysect is a store and forward device. Images are deleted off of dysect as soon as they are successfully routed to the configured destination. Compressed data is not accepted by the StoreP AE configuration. The duration of data reception is determined by the bandwidth and actual load of the local area network, extended with the processing time of the item on dysect. The processing time itself is typically much less than 1 second, but is never more than 3 seconds. The dysect will return an unsuccessful or C-STORE warning response in accordance with Unsuccessful/Warning Storage Responses. In all error cases, the SOP Instance is not permanently stored, and the source (Store SCU AE) system must retransmit them. Status Code Description 0106 (Invalid Attribute Tag) Indicates that the DICOM Command was neither a C-ECHO nor a C- STORE. Those are the only Service classes supported by the StoreP AE. The SCU must send one of the supported Service Classes. 11
Status Code A700 (Out of Resources) A701 (Missing Parameter) A702 (Creation Error) A703 (File Open Error) A704 (Database Access Error) C100 (Missing Command Attribute) C106 (Invalid Attribute) C111 (Duplicate Instance UID) C117 (Duplicate Image UID) C120 (Missing Attribute) F000 (Uncategorized Error) Description Indicates the StoreP AE is running low on memory or disk space. This also may indicate a network or computer system error that caused the failure. The user should use the system s log files to get more specific information about the nature of the error and try to resolve it. Indicates that a required parameter was not passed properly between software modules within the StoreP AE. The user should use the system s log files to get more specific information about the nature of the error and try to resolve it. Indicates that the StoreP AE failed to create an object or structure internally. This error is usually caused by low memory. Indicates that the StoreP AE failed to open an image file on disk. The user should use the system s log files to find the name of the file that it failed to open and make sure that it exists. Indicates that the StoreP AE failed to access the local database. The user should verify the database is running and that the configured username and password are correct. Indicates that the Attribute Command Field (0000,0100) was not present in the storage request message. This indicates a problem with the SCU of the Service Class. Indicates that the StoreP AE failed to parse or process a DICOM message. This usually indicates a problem with the SCU of the Service Class. Indicates the StoreP AE has received an image object whose Instance UID is already in use by another object stored in the dysect. Indicates the StoreP AE has received an image object whose Instance UID is already in use by another object stored in the dysect. Indicates that the Attribute Series Instance UID (0020,000E) was not present in the storage request message. This indicates a problem with the SCU of the Service Class. Uncategorized Error. See log files for more information to try to determine the cause of the problem. Table 3-3: Storage Response Codes 3.1.3.1.3.2 SOP Specific Conformance for Storage Commitment Push Model SOP Class This model uses the DICOM standard N-ACTION (for SCU request) and N-EVENT-REPORT (for response received) Service Classes. Both service class messages are handled via different associations, i.e. the request issuing association does not have to wait for the response, it is expected that the StoreP AE returns its response to the SCU via another association using reverse role negotiation for the special N-EVENT-REPORT message to the remote SCU. The remote SCU must be able to accept a reverse role negotiated association from the StoreP AE. During the association-negotiation process for the N-EVENT-REPORT response message the same presentation context will be used that the SCU used while sending the N-ACTION message. The Storage Media File Set ID attributes are not used/ignored in the dysect Storage Commitment request and response messages. 12
The Storage Commitment Request message accepted by a StoreP AE is specified in Table 3.1-4. The Action Code for the request message is 1. Attribute Description Tag Type Notes Transaction ID 0008 1195 1 Unique identifier for each message, generated by SCU, used by SCP in response Referenced SOP Sequence 0008 1199 1 > Referenced SOP Class UID 0008 1150 1 > Referenced SOP Instance UID 0008 1155 1 Referenced Study Component Sequence 0008 1111 1C Inserted only for Study level commitment, to list images, otherwise not sent > Referenced SOP Class UID 0008 1150 1 > Referenced SOP Instance UID 0008 1155 1 Table 3.1-4: dysect Storage Commitment Request The SCP will respond with an N-EVENT-REPORT event after one of three conditions is met. First, if Storage Commitment is not configured for the current destination then a response will be sent immediately listing all the requests with a failed status. Second, it will send a response after all of the images referenced in the commit request have been forwarded to their appropriate destination and the commit requests to that destination have been fulfilled. Third, it will send a response if a commit response was not received from the destination within a configured timeout period. The event type for Success response is 1; for the Failures Exists case the event type is 2. The Storage Commitment Result Information returned by the StoreP AE is specified in Table 3.1-5 and Table 3.1-6. Attribute Description Tag Type Notes Transaction ID 0008 1195 1 Same as the received Store Commit request's Transaction UID Retrieve AE Title 0008 0054 3 Must be empty if AE titles are listed inside the sequence (not filled) Referenced SOP Sequence 0008 1199 1 > Referenced SOP Class UID 0008 1150 1 > Referenced SOP Instance UID 0008 1155 1 > Retrieve AE Title 0008 0054 3 Must be empty if AE title is defined outside the sequence (not filled) Table 3.1-5 dysect Storage Commitment Result Success (Event type=1) 13
Attribute Description Tag Type Notes Transaction ID 0008 1195 1 Same as the received Store Commit request's Transaction UID Retrieve AE Title 0008 0054 3 Must be empty if AE titles are listed inside the sequence or on failure of all items (not filled) Referenced SOP Sequence 0008 1199 1C Will be provided only if 1 or more items were committed successfully > Referenced SOP Class UID 0008 1150 1 > Referenced SOP Instance UID 0008 1155 1 > Retrieve AE Title 0008 0054 3 Must be empty if AE titles are listed outside the sequence (not filled) Failed SOP Sequence 0008 1198 1 Lists all failed items > Referenced SOP Class UID 0008 1150 1 > Referenced SOP Instance UID 0008 1155 1 > Retrieve AE Title 0008 0054 3 Must be empty if AE title is defined outside the sequence (not filled) > Failure Reason 0008 1197 1 See Table 3.1-7 below for codes Table 3.1-6: dysect Storage Commitment Result Failures Exist (Event type=2) Code Meaning Description 0110H Processing failure A general failure in processing the operation was encountered. 0112H Resource limitation The SCP does not currently have enough resources to store the requested SOP Instance(s). 0112H No such object instance One or more of the elements in the Referenced SOP Instance Sequence was not available. 0213H Resource limitation The SCP does not currently have enough resources to store the requested SOP Instance(s). 0122H Referenced SOP Class not supported Storage Commitment has been requested for a SOP Instance with a SOP Class that is not supported by the SCP. 0119H Class / Instance conflict The SOP Class of an element in the Referenced SOP Instance Sequence did not correspond to the SOP class registered for this SOP Instance at the SCP. 0131H Duplicate transaction UID The Transaction UID of the Storage Commitment Request is already in use. Table 3.1-7: dysect Storage Commitment Failure Codes 14
3.1.3.1.4 Presentation Context Acceptance Criterion The StoreP AE will accept all supported presentation contexts that are listed in the configuration and match those offered by the requesting entity. 3.1.3.1.5 Transfer Syntax Selection Policies The transfer syntax accepted and applied to the presentation context will be the first one listed in the configuration that matches one offered by the requesting entity. The list is checked in the order they are offered by the requesting entity. 15
3.2 AE Specification StoreU AE The StoreU AE is used to forward image objects to one of three destinations (PACS Primary, PACS Failover, or QC). All image objects that are received by dysect are forwarded to one of these destinations after they are processed. Some images might be sent to the PACS destination twice. This can happen when the study that contains the image is successfully seperated and the image is within a configured overlap. The study may be optionally routed to a QC destination if it meets criteria specified in the Validation GUI. Otherwise the study will be routed to a PACS destination. The SOP Classes that the StoreU AE uses to send images is determined by the content of the images the dysect has stored on its local storage. Therefore the SOP Classes that the StoreU AE supports as an SCU is determined by the SOP Classes the StoreP AE supports as a SCP. Using that logic, the following statements can be made. By default, the StoreU AE provides standard conformance to the DICOM SOP classes listed in Table 3-8 as an SCU. Note also that if the StoreP AE receives an image that is not conformant to its SOP Class then the StoreU AE will not provide proper conformance to that SOP Class as an SCU when it sends that image to a remote entity. This is because the StoreU AE does not attempt to alter images to make them DICOM conformant. SOP Class Name SOP Class UID Computed Tomography Image Storage (CT) 1.2.840.10008.5.1.4.1.1.2 Table 3-8: Default SOP Classes supported by the Store AE 3.2.1 Association Establishment Policies 3.2.1.1 General The StoreU AE will attempt to establish an association whenever a study has been received and processed by dysect. The dysect will attempt to establish and association after a configurable amount of time if a study fails to send for whatever reason. The maximum PDU size offered is configurable, but the default is 4,096 bytes. 3.2.1.2 Number of Associations The maximum number of associtations the StoreU AE will initiate per destination simultaneously is configurable up to a maximum of eight. Only one association will be initiated per study. dysect will only attempt to send on multiple associations when multiple studies are queued to be forwarded. If studies are queued to be sent to both the PACS and a QC destination, dysect will attempt to send up to the maximum configured associations for each destination. 3.2.1.3 Asynchronous Nature The StoreU AE does not support asynchronous operations. 3.2.1.4 Implementation Identifying Information The implementation UID supplied is 2.16.840.1.113664.3.42.2. There is no implementation version name. 16
3.2.2 Association Initiation Policy The StoreU AE will attempt to establish an association whenever a study has been received and processed by dysect. The dysect will attempt to establish and association after a configurable amount of time if a study fails to send for whatever reason. 3.2.2.1 Associated Real-World Activity There are two possibilities for the associated real-world activity that causes the initiation of an association. One is the arrival of a new image or study that has been processed by dysect. The other is to attempt to re-send a study that has failed to send to a destination. dysect will only successfully send an image once to a destination. Once the image has been sent successfully it will be deleted from the dysect. 3.2.2.2 Presentation Context Table dysect will propose the DICOM Implicit VR Little Endian (1.2.840.10008.1.2) Transfer Syntax. The Abstract Syntax of the SOP Class UID is specified in the header of the image file to be transferred. 3.2.2.3 SOP Specific Conformance for all Storage Service SOP Classes The StoreU AE does not support extended negotiations. The DICOM Header of the images might be altered if one of two conditions is met. One possible condition is if the image is part of a study that has been identified as a candidate for separation and that study is successfully separated. The other possibility is if the enable window and level configuration option is set. All of the attributes that could be altered are listed in Table 3-9 Modified DICOM Header Attributes Table with the criteria for which they will be modified. Attribute Description Attribute Tag Modification Criteria Study Instance UID (0020,000D) Always modified if the image is part of a study that is successfully separated. Series Instance UID (0020,000E) Always modified if the image is part of a study that is successfully separated. Image Instance UID (0008,0018) Always modified if the image is part of a study that is successfully separated. Accession Number (0008,0050) Modified to match the original order information acquired by the DICOM Modality Worklist SCU (PACS) for a study that is successfully separated. Study Description (0008,1030) Modified to match the original order information acquired by the DICOM Modality Worklist SCU (PACS) for a study that is successfully separated. Patient Name (0010,0010) Modified to match the original order information acquired by the DICOM Modality Worklist SCU (PACS) for a study that is successfully separated. Patient ID (0010,0020) Modified to match the original order information acquired by the DICOM Modality Worklist SCU (PACS) for a study that is successfully separated. Patient Birth Date (0010,0030) Modified to match the original order information acquired by the DICOM Modality Worklist SCU (PACS) for a study that is successfully 17
Attribute Description Attribute Tag Modification Criteria separated. Patient Sex (0010,0040) Modified to match the original order information acquired by the DICOM Modality Worklist SCU (PACS) for a study that is successfully separated. Body Part (0018,0015) Modified to match the original order information acquired by the DICOM Modality Worklist SCU (PACS) for a study that is successfully separated. Window Width (0028,1051) Configured values inserted if the enable window and level configuration option is turned on. Window Center (0028,1050) Configured values inserted if the enable window and level configuration option is turned on. Table 3-9 Modified DICOM Header Attributes Table 3.2.2.4 Association Acceptance Policy The StoreU AE does not accept associations. 18
3.3 AE Specification - Modality Worklist User (MWLU) The dysect provides standard conformance to the DICOM Worklist Management as an SCU. 3.3.1 Association Establishment Policies The dysect establishes a new association each time it performs a query. The default application context is DICOM (1.2.840.10008.3.1.1.1). 3.3.1.1 General The presentation contexts that are offered by the MWLU AE are defined in the configuration. An association will be requested by the MWLU at time intervals defined in the configuration file. The association parameters are configured into the AE when the application is started. A single association remains open for the duration of the query. The default maximum PDU size offered for DICOM associations is 4,096 bytes; this can be changed in the configuration file. 3.3.1.2 Number of Associations The number of simultaneous associations the MWLU can support is one. 3.3.1.3 Asynchronous Nature Not applicable. 3.3.1.4 Implementation Identifying Information The implementation UID supplied for a DICOM association is 2.16.840.1.113664.1.1. There is no implementation version name. 3.3.2 Association Initiation Policy The MWLU attempts to initiate an association at periodic intervals. The number of queries per association is one. The basic form of real-world activity is the generic demographic query. 3.3.2.1 Real-World Activity 3.3.2.1.1 Associated Real-World Activity The real-world activity that causes the MWLU to request associations are the dysect starting and the configured time interval has expired. 3.3.2.1.2 Proposed Presentation Contexts The MWLU AE will offer a single presentation context in each association request. The presentation contexts available for use are listed in the following table. 19
Abstract Syntax Transfer Syntax Role Extended Name UID Name List UID List Negotiation Modality Worklist Information Model FIND 1.2.840.10008.5.1.4.31 DICOM Implicit VR Little Endian 1.2.840.10008.1.2 SCU None Table 3-10: Presentation Context Table 3.3.2.1.2.1 SOP Specific Conformance for Modality Worklist Management The dysect MWLU AE provides standard conformance to the Modality Worklist Management SOP Class as an SCU. No hierarchical searches are requested and therefore no extended negotiation is used. The MWLU AE requests the attributes listed in the following table: Attribute Description Attribute Tag Description of Requested Value Accession Number (0008,0050) Zero length Institution Name (0008,0080) Zero length Referring Physician (0008,0090) Zero length Study Description (0008,1030) Zero length Reading Physician (0008,1060) Zero length Operator s Name (0008,1070) Zero length Referenced Study Sequence (0008,1110) Zero length > Referenced Study Class UID (0008,1150) Zero length > Referenced Study Instance UID (0008,1155) Zero length Referenced Patient Sequence (0008,1120) Zero length > Referenced Patient Class UID (0008,1150) Zero length > Referenced Patient Instance UID (0008,1155) Zero length Patient s Name (0010,0010) Zero length Patient ID (0010,0020) Zero length Patient s Birth Date (0010,0030) Zero length Patient s Sex (0010,0040) Zero length Other Patient IDs (0010,1000) Zero length Patient s Age (0010,1010) Zero length Patient s Size (0010,1020) Zero length Patient s Weight (0010,1030) Zero length Patient s Address (0010,1040) Zero length Medical Alerts (0010,2000) Zero length Contras Allergies (0010,2110) Zero length Patient s Phone Number (0010,2154) Zero length Ethnic Group (0010,2160) Zero length Smoking Status (0010,21A0) Zero length Additional Patient History (0010,21B0) Zero length Pregnancy Status (0010,21C0) Zero length Patient Comments (0010,4000) Zero length Study Instance UID (0020,000D) Zero length Study ID (0020,0010) Zero length Study Status ID (0032,000A) Zero length Requesting Physician (0032,1032) Zero length Requested Service (0032,1033) Zero length Requested Procedure Description (0032,1060) Zero length Requested Procedure Code Sequence (0032,1064) Zero length 20
Attribute Description Attribute Tag Description of Requested Value > Code Value (0008,0100) Zero length > Code Scheme (0008,0102) Zero length > Code Meaning (0008,0104) Zero length Requested Contrast Agent (0032,1070) Zero length Admission ID (0038,0010) Zero length Special Needs (0038,0050) Zero length Current Patient Location (0038,0300) Zero length Patient State (0038,0500) Zero length Scheduled Procedure Step Sequence (0040,0100) Zero length > Modality (0008,0060) CT > Scheduled Station AE Title (0040,0001) Zero length >Scheduled Procedure Step Start Date (0040,0002) Zero length >Scheduled Procedure Step Start Time (0040,0003) Zero length >Performing Physicians Name (0040,0006) Zero length >Scheduled Procedure Step Description (0040,0007) Zero length >Action Item Sequence (0040,0008) Zero length >> Code Value (0008,0100) Zero length >> Code Value (0008,0102) Zero length >> Code Value (0008,0104) Zero length >Scheduled Procedure Step ID (0040,0009) Zero length >Scheduled Station Name (0040,0010) Zero length > Scheduled Procedure Step Location (0040,0011) Zero length >Pre-Medication (0040,0012) Zero length >Scheduled Procedure Step Status (0040,0020) Zero length >Scheduled Procedure Step Comments (0040,0400) Zero length Requested Procedure Step ID (0040,1001) Zero length Reason for Requested Procedure (0040,1002) Zero length Requested Procedure Priority (0040,1003) Zero length Patient Transportation Arrangements (0040,1004) Zero length Requested Procedure Location (0040,1005) Zero length Imaging Service Request (0040,1008) Zero length Confidentiality Code Imaging Service Request Issue Date (0040,2004) Zero length Imaging Service Request Issue Time (0040,2005) Zero length Names of Intended Recipients of (0040,1010) Zero length Results Requested Procedure Comments (0040,1400) Zero length Placer Order Number (0040,0016) Zero length Filler Order Number (0040,0017) Zero length Imaging Service Request Comments (0040,2400) Zero length Confidentiality Constraint Description (0040,3001) Zero length Table 3-11: Requested Attribute Table 3.3.3 Association Acceptance Policy The MWLU AE does not accept associations at any time. 21
3.4 AE Specification Modality Worklist Provider (MWLP) The Modality Worklist Provider AE (MWLP AE) provides conformance to the following DICOM SOP classes as an SCP: SOP Class Name SOP Class UID Verification 1.2.840.10008.1.1 Modality Worklist Management 1.2.840.10008.5.1.4.31 Table 3-12: Modality Work List SCP AE Supported SOP Classes The MWLP AE does not operate as an SCU of any SOP class. 3.4.1 Association Establishment Policies 3.4.1.1 General Any time after the dysect has initialized the MWLP can accept associations. An association is accepted if resources are available, the called AE Title matches the MWLP AE Title, the application context is 1.2.840.10008.3.1.1.1, and there is at least one presentation context in the association request that matches one of the presentation contexts defined in the presentation context table. The maximum PDU size offered is 4,096 bytes. 3.4.1.2 Number of Associations The MWLP AE can accommodate up to 32 simultaneous associations. However, the resources available to underlying communication drivers and the operating system may limit the total number of simultaneous associations that the MWLP AE can support. The communication and operating system resources may vary based on the hardware configuration used. 3.4.1.3 Asynchronous Nature Not applicable. 3.4.1.4 Implementation Identifying Information The implementation UID supplied is 2.16.840.1.113664.3.5. There is no implementation version name. 3.4.2 Association Initiation Policy The MWLP AE does not initiate any associations. 22
3.4.3 Association Acceptance Policy The MWLP AE will accept an association when a remote AE provides an acceptable application context and at least one supported presentation context. The MWLP AE does not interpret the remote entity s AE title or its implementation UID. 3.4.3.1 Fulfilling Queries The MWLP AE will accept associations to fulfill a query from a query client AE. 3.4.3.1.1.1 Associated Real-World Activity The real-world activity that causes the MWLP AE to accept an association is a remote entity requesting an association for the purpose of retrieving information from the database either via the Modality Worklist SOP Class or one of the Detached Management SOP Classes proposed below. 3.4.3.1.2 Presentation Context Table The acceptable presentation contexts for the MWLP AE are listed in the following table. Abstract Syntax Transfer Syntax Role Extended Name UID Name List UID List Negotiation Verification 1.2.840.10008.1.1 DICOM Implicit VR Little Endian Modality Worklist Information Model FIND 1.2.840.10008.5.1.4.31 DICOM Implicit VR Little Endian 1.2.840.10008.1.2 SCP None 1.2.840.10008.1.2 SCP None Table 3-13: Presentation Context Table 3.4.3.1.2.1 SOP Specific Conformance for Verification SOP Class The MWLP AE provides standard conformance for the Verification SOP Class as an SCP. 3.4.3.1.2.2 SOP Specific Conformance for Modality Worklist SOP Class The MWLP AE provides conformance to the Modality Worklist Management SOP Class as an SCP. Relational queries are not supported and therefore no extended negotiation is used. ISO IR-6 and IR-100 character sets are supported only. The table below lists all attributes supported by the Worklist Manager. 23
Attribute Descriptions Attribute Tags Specific Character set (0008,0005) Accession Number (0008,0050) Institution (0008,0080) Referring Physician s Name (0008,0090) Study Description (0008,1030) Operator s Name (0008,1070) Referenced Study Sequence (0008,1110) >Referenced SOP Class UID (0008,1150) >Referenced SOP Instance UID (0008,1155) Referenced Patient Sequence (0008,1120) >Referenced SOP Class UID (0008,1150) >Referenced SOP Instance UID (0008,1155) Patient s Name (0010,0010) Patient ID (0010,0020) Patient s Birth Date (0010,0030) Patient s Sex (0010,0040) Other Patient ID (0010,1000) Patient s Age (0010,1010) Patient s Size (0010,1020) Patient s Weight (0010,1030) Patient s Address (0010,1040) Medical Alerts (0010,2000) Contrast Allergies (0010,2110) Patient s Telephone Numbers (0010,2154) Ethnic Group (0010,2160) Smoking Status (0010,21A0) Additional Patient History (0010,21B0) Pregnancy Status (0010,21C0) Patient Comments (0010,4000) Protocol Name (0018,1030) Study ID (0020,0010) Study Instance UID (0020,000D) Requesting Physician (0032,1032) Requested Service (0032,1033) Requested Procedure Description (0032,1060) Requested Procedure Code Sequence (0032,1064) Code value (0008,0100) Code Scheme (0008,0102) Code Meaning (always blank) (0008,0104) Admission ID (0038,0010) 24
Attribute Descriptions Attribute Tags Special Needs (0038,0050) Current Patient Location (0038,0300) Patient State (0038,0500) Scheduled Procedure Step Sequence (0040,0100) >Modality (0008,0060) >Requested Contrast Agent (0032,1070) >Scheduled Station AE Title (0040,0001) >Scheduled Procedure Step Start Date (0040,0002) >Scheduled Procedure Step Start Time (0040,0003) >Performing Physician Name (0040,0006) >Scheduled Procedure Step Description (0040,0007) >Action Item Sequence (always blank) (0040,0008) >>Code Value (always blank) (0008,0100) >>Code Scheme (always blank) (0008,0102) >>Code Meaning (always blank) (0008,0104) >Scheduled Procedure Step ID (0040,0009) >Scheduled Station Name (0040,0010) >Scheduled Procedure Step Location (0040,0011) >Pre-Medication (0040,0012) >Scheduled Procedure Step Status (0040,0020) >Scheduled Procedure Step Comments (0040,0400) Requested Procedure Step ID (0040,1001) Requested Procedure Priority (0040,1003) Patient s Transportation Arrangement (0040,1004) Requested Procedure Location (always blank) (0040,1005) Imaging Service Request Confidentiality Code (0040,1008) Imaging Service Request Issue Date (0040,2004) Imaging Service Request Issue Time (0040,2005) Names of Intended Recipients of Results (0040,1010) Requested Procedure Comments (0040,1400) Placer Order Number (0040,0016) Filler Order Number (0040,0017) Imaging Service Request Comments (0040,2400) Confidentiality Constraint on Patient Data Description (0040,3001) Table 3-14: Supported Attribute Table All attributes listed in Table 3-14 are supported for existence except SPS Action Item Code Sequence (0040, 0008). If the SPS Action Item Code Sequence is requested, it can be omitted from the response message through a registry configuration option. By default it is returned if requested. All non-italic attributes in Table 3-14 are supported for matching except for the Referenced SOP Class UID (0008,1150) in the Referenced Study and Patient sequences which is only supported for existence. 25
Single value matching, universal matching, wild card matching, sequence matching, and range matching are supported by the MWLP AE. List of UID matching is not supported by the MWLP AE. Requested attributes not supported by the MWLP AE will be ignored, causing any match responses to have a warning status of 0xFF01 instead of the normal status of 0xFF00. The MWLP AE will return zero length values for any attributes (including Type 1) that do not have a value in the database. Single value matching and wild card matching of all elements with a multiplicity of one is case-insensitive, contrary to section C.2.2.2 of Part 4 of the DICOM Standard. The MWLP AE does not support processing of priority requests. Due to the nature of the query processing, the MWLP AE cannot accept cancel requests. The MWLP AE will also allow the Type 2 attributes shown in the following table to be queried. Attribute Descriptions Attribute Tags Scheduled Performing Physician s Name 1 (0040,0006) Scheduled Station Name 1 (0040,0010) Requested Procedure Priority (0040,1003) Patient Transport Arrangements (0040,1004) Patient Data Confidentiality Constraint Description (0040,3001) Table 3-15: Type 2 Attribute Table 3.4.3.1.3 Presentation Context Acceptance Criterion The MWLP AE will accept all supported presentation contexts that match those offered by the requesting entity. 3.4.3.1.4 Transfer Syntax Selection Policies The transfer syntax accepted and applied to the presentation context will be the first one that matches the list specified in the presentation context table. The list is checked in the order entered into the presentation context table. 1 This attribute appears in the Scheduled Procedure Step Sequence 26