Shimadzu SDR-120 User Manual
No. : S517-E102
Rev. :A
DICOM Conformance Statement
ｆor OPESCOPE ACTENO
(SDR-120 Rev01.00.xx)
2
NO TEXT
S517-E102A
3
Overview:
SOP Classes
User of Services (SCU)
Provider of Services (SCP)
Transfer
X-Ray Radiofluoroscopic
Image Storage
Yes
No
X-Ray Angiographic
Image Storage
Yes
No
X-Ray Radiation Dose SR
Storage
Yes
No
Workflow Management
Modality Worklist Information
Model – FIND
Yes
No
Modality Performed Procedure
Step
Yes
No
Print Management
Basic Grayscale Print
Management Meta
Yes
No
Basic Film Session
Yes
No
Basic Film Box
Yes
No
Basic Grayscale Image Box
Yes
No
Printer
Yes
No
Print Job
Yes
No
Media Storage Application
Profile
Write Files
(FSC or FSU)
Read Files (FSR)
DVD
General Purpose CD-R
Yes
No
This conformance statement details the compliance to DICOM 3.0 of Digital Radiography SDR-120
mounted in the OPESCOPE ACTENO system.
Table below provides an overview of the network services supported by the SDR-120.
NETWORK SERVICES
Table below provides an overview of the Media Storage Application Profiles supported by the SDR-120.
S517-E102A
MEDIA SERVICES
4
TABLE OF CONTENTS:
1. INTRODUCTION .................................................................................................................................................... 5
1.1. REVISION HISTORY .............................................................................................................................................. 5
1.2. AUDIENCE ............................................................................................................................................................ 5
1.3. REMARKS .............................................................................................................................................................. 5
1.4. TERMS AND DEFINITIONS .................................................................................................................................... 6
1.5. BASICS OF DICOM COMMUNICATION ........................................................................................................... 8
1.6. ABBREVIATIONS ................................................................................................................................................... 9
1.7. REFERENCES ......................................................................................................................................................... 9
2. NETWORKING ..................................................................................................................................................... 10
2.1. IMPLEMENTATION MODEL ...............................................................................................................................10
2.1.1. Application Data Flow ............................................................................................................................10
2.1.2. Functional Definitions of AE’s .................................................................................................................12
2.1.3. Sequencing of Real-World Activities.....................................................................................................13
2.2. AE SPECIFICATIONS ..........................................................................................................................................15
2.2.1. Storage Application Entity Specification .............................................................................................15
2.2.2. Workflow Application Entity Specification ..........................................................................................21
2.2.3. Hardcopy Application Entity Specification .........................................................................................36
2.3. NETWORK INTERFACES .....................................................................................................................................47
2.3.1. Physical Network Interface .....................................................................................................................47
2.3.2. IPv4 and IPv6 Support ..............................................................................................................................47
2.4. CONFIGURATION ..............................................................................................................................................48
2.4.1. AE Title/Presentation Address Mapping ...............................................................................................48
2.4.2. Parameters ................................................................................................................................................49
3. MEDIA INTERCHANGE ....................................................................................................................................... 50
3.1. IMPLEMENTATION MODEL ...............................................................................................................................50
3.1.1. Application Data Flow ............................................................................................................................50
3.1.2. Functional Definition of AE’s ...................................................................................................................50
3.1.3. Sequencing of Real-World Activities.....................................................................................................50
3.1.4. File Meta Information Options ...............................................................................................................50
3.2. AE SPECIFICATIONS ..........................................................................................................................................51
3.2.1. Offline-Media Application Entity Specification ..................................................................................51
3.3. AUGMENTED AND PRIVATE APPLICATION PROFILES ...................................................................................52
3.4. MEDIA CONFIGURATION .................................................................................................................................52
4. SUPPORT OF CHARACTER SETS ......................................................................................................................... 53
5. SECURITY ............................................................................................................................................................ 53
6. ANNEXES ............................................................................................................................................................ 54
6.1. IOD CONTENTS ..................................................................................................................................................54
6.1.1. Created SOP Instances ...........................................................................................................................54
6.1.2. Used Fields in received IOD by application ........................................................................................82
6.1.3. Attribute mapping....................................................................................................................................82
6.1.4. Coerced/Modified Fields ........................................................................................................................83
6.2. DATA DICTIONARY OF PRIVATE ATTRIBUTES ..................................................................................................84
6.3. CODED TERMINOLOGY AND TEMPLATES ..................................................................................................................84
6.4. GRAYSCALE IMAGE CONSISTENCY .........................................................................................................................84
6.5. STANDARD EXTENDED/SPECIALIZED/PRIVATE SOP CLASSES .....................................................................................84
6.6. PRIVATE TRANSFER SYNTAXES ..................................................................................................................................84
S517-E102A
5
1. INTRODUCTION
Revision
Date
Description
First Edition
2014/01
New Release
A
2014/04
Modified the figure in ‘6.1.1.5.1 Template Structure’.
1.1. REVISION HISTORY
1.2. AUDIENCE
This document is written for the people that need to understand how the SDR-120 will integrate into their
healthcare facility. This includes both those responsible for overall imaging network policy and architecture,
as well as integrators who need to have a detailed understanding of the DICOM features of the product.
This document contains some basic DICOM definitions so that any reader may understand how this product
implements DICOM features. However, integrators are expected to fully understand all the DICOM
terminology, how the tables in this document relate to the product’s functionality, and how that
functionality integrates with other devices that support compatible DICOM features.
1.3. REMARKS
The scope of this DICOM Conformance Statement is to facilitate integration between the SDR-120 and
other DICOM products. The Conformance Statement should be read and understood in conjunction with the
DICOM Standard. DICOM by itself does not guarantee interoperability. The Conformance Statement does,
however, facilitate a first-level comparison for interoperability between different applications supporting
compatible DICOM functionality.
This Conformance Statement is not supposed to replace validation with other DICOM equipment to ensure
proper exchange of intended information. In fact, the user should be aware of the following important
issues:
- The comparison of different Conformance Statements is just the first step towards assessing
interconnectivity and interoperability between the product and other DICOM conformant equipment.
- Test procedures should be defined and executed to validate the required level of interoperability
with specific compatible DICOM equipment, as established by the healthcare facility.
S517-E102A
6
1.4. TERMS AND DEFINITIONS
Informal definitions are provided for the following terms used in this Conformance Statement. The DICOM
Standard is the authoritative source for formal definitions of these terms.
Abstract Syntax – the information agreed to be exchanged between applications, generally equivalent to
a Service/Object Pair (SOP) Class.
Examples : Verification SOP Class, Modality Worklist Information Model Find SOP Class, Computed
Radiography Image Storage SOP Class.
Application Entity (AE) – an end point of a DICOM information exchange, including the DICOM
network or media interface software; i.e., the software that sends or receives DICOM information objects
or messages. A single device may have multiple Application Entities.
Application Entity Title – the externally known name of an Application Entity, used to identify a
DICOM application to other DICOM applications on the network.
Application Context – the specification of the type of communication used between Application Entities.
Example: DICOM network protocol.
Association – a network communication channel set up between Application Entities.
Attribute – a unit of information in an object definition; a data element identified by a tag. The
information may be a complex data structure (Sequence), itself composed of lower level data elements.
Examples: Patient ID (0010,0020), Accession Number (0008,0050), Photometric Interpretation
(0028,0004), Procedure Code Sequence (0008,1032).
Information Object Definition (IOD) – the specified set of Attributes that comprise a type of data
object; does not represent a specific instance of the data object, but rather a class of similar data objects
that have the same properties. The Attributes may be specified as Mandatory (Type 1), Required but
possibly unknown (Type 2), or Optional (Type 3), and there may be conditions associated with the use of
an Attribute (Types 1C and 2C).
Examples: MR Image IOD, CT Image IOD, Print Job IOD.
Module – a set of Attributes within an Information Object Definition that are logically related to each
other.
Example: Patient Module includes Patient Name, Patient ID, Patient Birth Date, and Patient Sex.
Negotiation – first phase of Association establishment that allows Application Entities to agree on the
types of data to be exchanged and how that data will be encoded.
Presentation Context – the set of DICOM network services used over an Association, as negotiated
between Application Entities; includes Abstract Syntaxes and Transfer Syntaxes.
Protocol Data Unit (PDU) – a packet (piece) of a DICOM message sent across the network. Devices
must specify the maximum size packet they can receive for DICOM messages.
Service Class Provider (SCP) – role of an Application Entity that provides a DICOM network service;
typically, a server that performs operations requested by another Application Entity (Service Class User).
Examples: Picture Archiving and Communication System (image storage SCP, and image query/retrieve
SCP), Radiology Information System (modality worklist SCP).
S517-E102A
7
Service Class User (SCU) – role of an Application Entity that uses a DICOM network service; typically,
a client.
Examples: imaging modality (image storage SCU, and modality worklist SCU), imaging workstation
(image query/retrieve SCU)
Service/Object Pair (SOP) Class – the specification of the network or media transfer (service) of a
particular type of data (object); the fundamental unit of DICOM interoperability specification. Examples:
Ultrasound Image Storage Service, Basic Grayscale Print Management.
Service/Object Pair (SOP) Instance – an information object; a specific occurrence of information
exchanged in a SOP Class.
Examples: a specific x-ray image.
Tag – a 32-bit identifier for a data element, represented as a pair of four digit hexadecimal numbers, the
“group” and the “element”. If the “group” number is odd, the tag is for a private (manufacturer-specific)
data element.
Examples: (0010,0020) [Patient ID], (07FE,0010) [Pixel Data], (0019,0210) [private data element]
Transfer Syntax – the encoding used for exchange of DICOM information objects and messages.
Examples: JPEG compressed (images), little endian explicit value representation.
Unique Identifier (UID) – a globally unique “dotted decimal” string that identifies a specific object or a
class of objects; an ISO-8824 Object Identifier.
Examples: Study Instance UID, SOP Class UID, SOP Instance UID.
Value Representation (VR) – the format type of an individual DICOM data element, such as text, an
integer, a person’s name, or a code. DICOM information objects can be transmitted with either explicit
identification of the type of each data element (Explicit VR), or without explicit identification (Implicit
VR); with Implicit VR, the receiving application must use a DICOM data dictionary to look up the format
of each data element.
S517-E102A
8
1.5. BASICS OF DICOM COMMUNICATION
This section describes terminology used in this Conformance Statement for the non-specialist. The key
terms used in the Conformance Statement are highlighted in italics below. This section is not a substitute
for training about DICOM, and it makes many simplifications about the meanings of DICOM terms.
Two Application Entities (devices) that want to communicate with each other over a network using DICOM
protocol must first agree on several things during an initial network “handshake”. One of the two devices
must initiate an Association (a connection to the other device), and ask if specific services, information, and
encoding can be supported by the other device (Negotiation).
DICOM specifies a number of network services and types of information objects, each of which is called an
Abstract Syntax for the Negotiation. DICOM also specifies a variety of methods for encoding data, denoted
Transfer Syntaxes. The Negotiation allows the initiating Application Entity to propose combinations of
Abstract Syntax and Transfer Syntax to be used on the Association; these combinations are called
Presentation Contexts. The receiving Application Entity accepts the Presentation Contexts it supports.
For each Presentation Context, the Association Negotiation also allows the devices to agree on Roles –
which one is the Service Class User (SCU - client) and which is the Service Class Provider (SCP - server).
Normally the device initiating the connection is the SCU, i.e., the client system calls the server, but not
always.
The Association Negotiation finally enables exchange of maximum network packet (PDU) size, security
information, and network service options (called Extended Negotiation information).
The Application Entities, having negotiated the Association parameters, may now commence exchanging
data. Common data exchanges include queries for worklists and lists of stored images, transfer of image
objects and analyses (structured reports), and sending images to film printers. Each exchangeable unit of
data is formatted by the sender in accordance with the appropriate Information Object Definition, and sent
using the negotiated Transfer Syntax. There is a Default Transfer Syntax that all systems must accept, but it
may not be the most efficient for some use cases. Each transfer is explicitly acknowledged by the receiver
with a Response Status indicating success, failure, or that query or retrieve operations are still in process.
Two Application Entities may also communicate with each other by exchanging media (such as a DVD-R).
Since there is no Association Negotiation possible, they both use a Media Application Profile that specifies
“pre-negotiated” exchange media format, Abstract Syntax, and Transfer Syntax.
S517-E102A
9
1.6. ABBREVIATIONS
AE Application Entity
AET Application Entity Title
CR Computed Radiography
CT Computed Tomography
DHCP Dynamic Host Configuration Protocol
DICOM Digital Imaging and Communications in Medicine
DNS Domain Name System
DX Digital X-ray
GSDF Grayscale Standard Display Function
GSPS Grayscale Softcopy Presentation State
HIS Hospital Information System
IHE Integrating the Healthcare Enterprise
IOD Information Object Definition
IPv4 Internet Protocol version 4
ISO International Organization for Standardization
LDAP Lightweight Directory Access Protocol
LUT Look-up Table
MPPS Modality Performed Procedure Step
MSPS Modality Scheduled Procedure Step
MWL Modality Worklist
NTP Network Time Protocol
PACS Picture Archiving and Communication System
PDU Protocol Data Unit
RF Radiofluoroscopy
RIS Radiology Information System
SCP Service Class Provider
SCU Service Class User
SOP Service-Object Pair
SPS Scheduled Procedure Step
TCP/IP Transmission Control Protocol/Internet Protocol
UL Upper Layer
VM Value Multiplicity
VR Value Representation
1.7. REFERENCES
NEMA PS3 Digital Imaging and Communications in Medicine (DICOM) Standard, available
free at http://dicom.nema.org/
S517-E102A
10
2. NETWORKING
Update
Worklist
Storage
Application
Entity
Send Images
Remote
Application
Entity Receives
Images
Workflow
Application
Entity
Open/Close
Study
Hardcopy
Application
Entity
Film
Images
Remote
Application
Entity Provides
Worklist Items
Remote
Application
Entity Receives
MPPS
Create/Update
Remote
Application
Entity Prints
Film Sheets
2.1. IMPLEMENTATION MODEL
2.1.1. Application Data Flow
APPLICATION DATA FLOW DIAGRAM
Figure 2.1-1
S517-E102A
11
The Storage Application Entity sends images to a remote AE. It is associated with the local real-world
activity “Send Images”. “Send Images” is performed upon user request for each radiography/study or
for specific images selected. When activated by user’s settings (auto-send), each marked set of images
can be immediately stored to a preferred destination whenever next radiography is performed or a
Patient/Study is closed by the user.
The Workflow Application Entity receives Worklist information from and sends MPPS information to a
remote AE. It is associated with the local real-world activities “Update Worklist” and “Open/Close
Study”. When the “Update Worklist” local real-world activity is performed the Workflow Application
Entity queries a remote AE for worklist items and provides the set of worklist items matching the query
request. “Update Worklist” is performed as a result of an operator request or can be performed
automatically at specific operation. When the “Open/Close Study” local real-world activity is performed
the Worklist Application Entity creates and updates Modality Performed Procedure Step instances
managed by a remote AE. Opening Study will result in automated creation of an MPPS Instance.
Completion of the MPPS is performed as the result of an operator action.
The Hardcopy Application Entity prints images on a remote AE (Printer). It is associated with the realworld activity “Film Images”. “Film Images” creates a print-job within the print queue containing one
or more virtual film sheets composed from images selected by the user.
S517-E102A
12
2.1.2. Functional Definitions of AE’s
2.1.2.1. Functional Definition of Storage Application Entity
The existence of a send-job queue entry with associated network destination will activate the Storage
AE. An association request is sent to the destination AE and upon successful negotiation of a
Presentation Context the image transfer is started. If the association cannot be opened, the related sendjob is set to an error state and can be restarted by the user via job control interface. By default, the
Storage AE will not try to initiate another association for this send-job automatically.
2.1.2.2. Functional Definition of Workflow Application Entity
Worklist Update attempts to download a Worklist from a remote node. If the Workflow AE establishes
an Association to a remote AE, it will transfer all worklist items via the open Association. During
receiving the worklist response items are counted and the query processing is canceled if the
configurable limit of items is reached. The result will be displayed in a separate list, which can be
cleared with the next Worklist Update based on the configuration.
The Workflow AE performs the creation of a MPPS Instance automatically whenever studies are started.
Further updates on the MPPS data can be performed interactively from the related MPPS user interface.
The MPPS “Complete” or “Discontinued” states can only be set from the user interface.
2.1.2.3. Functional Definition of Hardcopy Application Entity
The existence of a print-job in the print queue will activate the Hardcopy AE. An association is
established with the printer and the printer’s status determined. If the printer is operating normally, the
film sheets described within the print-job will be printed. Changes in printer status will be detected (e.g.
out of film) and reported to the user. If the printer is not operating normally, the print-job will set to an
error state and can be restarted by the user via the job control interface.
S517-E102A
13
2.1.3. Sequencing of Real-World Activities
Department
Scheduler
Storage Hardcopy Workflow Printer
Image
Manager
1. Query Worklist
2. Receive Worklist
3. Select Workitem (MSPS)
4. Start Study (Create MPPS)
5. Acquire Images
6. Complete Study (Finalize MPPS)
7. Print Acquired Images
8. Store Acquired Images
Department
Scheduler
Storage Hardcopy Workflow Printer
Image
Manager
1. Query Worklist
2. Receive Worklist
3. Select Workitem (MSPS)
4. Start Study (Create MPPS)
5. Acquire Images
6. Complete Study (Finalize MPPS)
7. Print Acquired Images
8. Store Acquired Images
Figure 2.1-2 SEQUENCING CONSTRAINTS
Under normal scheduled workflow conditions the sequencing constraints illustrated in Figure 2-1-2
apply;.
1. Query Worklist
2. Receive Worklist of Modality Scheduled Procedure Steps (MSPS)
3. Select Workitem (MSPS) from Worklist
4. Start Study and create MPPS
5. Acquire Images
6. Complete Study and finalize MPPS
7. Print acquired images (optional step)
8. Store acquired images
S517-E102A
14
Other workflow situations (e.g. unscheduled procedure steps) will have other sequencing constraints.
Printing could equally take place after the acquired images have been stored. Printing could be omitted
completely if no printer is connected or hardcopies are not required.
S517-E102A
15
2.2. AE SPECIFICATIONS
SOP Class Name
SOP Class UID
SCU
SCP
X-Ray
Radiofluoroscopic
Image Storage
1.2.840.10008.5.1.4.1.1.12.2
Yes
No
X-Ray
Angiographic
Image Storage
1.2.840.10008.5.1.4.1.1.12.1
Yes
No
XRay
Radiation Dose
SR Storage
1.2.840.10008.5.1.4.1.1.88.67
Yes
No
Application Context Name
1.2.840.10008.3.1.1.1
Maximum number of simultaneous Associations
1
2.2.1. Storage Application Entity Specification
2.2.1.1. SOP Classes
The SDR-120 provides Standard Conformance to the following SOP Classes:
Table 2.2-1
SOP CLASSES FOR AE STORAGE
2.2.1.2. Association Policies
2.2.1.2.1. General
The DICOM standard application context name for DICOM 3.0 is always proposed:
DICOM APPLICATION CONTEXT FOR AE STORAGE
2.2.1.2.2. Number of Associations
The SDR-120 initiates one Association at a time for each destination to which a transfer request is being
processed in the active job queue list. Only one job will be active at a time, the other remains pending
until the active job is completed or failed.
NUMBER OF ASSOCIATIONS INITIATED FOR AE STORAGE
Table 2.2-2
Table 2.2-3
S517-E102A
16
2.2.1.2.3. Asynchronous Nature
Maximum number of outstanding asynchronous
transactions
1
Implementation Class UID
1.2.392.200036.9110.1.0.6711.2001002
Implementation Version Name
SPF XX (XX : version number)
The SDR-120 does not support asynchronous communication (multiple outstanding transactions over a
single Association).
ASYNCHRONOUS NATURE AS A SCU FOR AE STORAGE
2.2.1.2.4. Implementation Identifying Information
The implementation information for this Application Entity is:
DICOM IMPLEMENTATION CLASS AND VERSION FOR AE STORAGE
2.2.1.3. Association Initiation Policy
2.2.1.3.1. Activity – Send Images
2.2.1.3.1.1. Description and Sequencing of Activities
A user can select images and request them to be sent to multiple destinations. Each request is forwarded
to the job queue and processed individually. When the “Auto-send” option is active, each marked
instance or marked set of instances stored in database will be forwarded to the network job queue for a
pre-configured auto-send target destination. It can be configured which instances will be automatically
marked and the destination where the instances are automatically sent to. The “Auto-send” is triggered
by the next acquisition.
Table 2.2-4
Table 2.2-5
The Storage AE is invoked by the job control interface that is responsible for processing network
archival tasks. The job consists of data describing the instances marked for storage and the destination.
An internal daemon process triggered by a job for a specific network destination initiates a C-STORE
request to store images. If the process successfully establishes an Association to a remote Application
Entity, it will transfer each marked instance one after another via the open Association. Status of the
transfer is reported through the job control interface. Only one job will be active at a time. If the CSTORE Response from the remote Application contains a status other than Success or Warning, the
Association is aborted and the related Job is switched to a failed state. It can be restarted any time by
user interaction.
The Storage AE attempts to initiate a new Association in order to issue a C-STORE request. If the job
contains multiple images then multiple C-STORE requests will be issued over the same Association.
S517-E102A
17
Storage AE
Image
Manager
1. Open Association
2. C-STORE (Image)
3. C-STORE (Image)
4. Close Association
Storage AE
Image
Manager
1. Open Association
2. C-STORE (Image)
3. C-STORE (Image)
4. Close Association
Figure 2.2-1 SEQUENCE OF ACTIVITY – SEND IMAGES
A possible sequence of interactions between the Storage AE and an Image Manager (e.g. a storage or
archive device supporting the Storage SOP Class as an SCP) is illustrated in Figure above:
1. The Storage AE opens an association with the Image Manager
2. An acquired image is transmitted to the Image Manager using a C-STORE request and the
Image Manager replies with a C-STORE response (status success).
3. Another acquired image is transmitted to the Image Manager using a C-STORE request and the
Image Manager replies with a C-STORE response (status success).
4. The Storage AE closes the association with the Image Manager.
NOTE: Many other message sequences are possible depending on the number of images to be stored.
S517-E102A
18
2.2.1.3.1.2. Proposed Presentation Contexts
Presentation Context Table
Abstract Syntax
Transfer Syntax
Role
Ext.
Neg.
Name
UID
Name
UID
X-Ray Radio
Fluoroscopic Image
Storage
1.2.840.10008.5.1
.4.1.1.12.2
Implicit VR Little Endian
Explicit VR Little Endian
Explicit VR Big Endian
1.2.840.10008.1.2
1.2.840.10008.1.2.1
1.2.840.10008.1.2.2
SCU
None
X-Ray Angiographic
Image Storage
1.2.840.10008.5.1
.4.1.1.12.1
Implicit VR Little Endian
Explicit VR Little Endian
Explicit VR Big Endian
1.2.840.10008.1.2
1.2.840.10008.1.2.1
1.2.840.10008.1.2.2
SCU
None
X-Ray Radiation
Dose SR Storage
1.2.840.10008.5.1
.4.1.1.88.67
Implicit VR Little Endian
Explicit VR Little Endian
Explicit VR Big Endian
1.2.840.10008.1.2
1.2.840.10008.1.2.1
1.2.840.10008.1.2.2
SCU
None
The SDR-120 is capable of proposing the Presentation Contexts shown in the following table:
PROPOSED PRESENTATION CONTEXTS FOR ACTIVITY SEND IMAGES
Presentation Contexts for each Image Storage will only be proposed if the Send Job contains instances
for these SOP Classes.
Table 2.2-6
S517-E102A
19
2.2.1.3.1.3. SOP Specific Conformance Image Storage SOP Classes
Service
Status
Further Meaning
Error
Code
Behavior
Success
Success
0000
The SCP has successfully stored the SOP Instance.
If all SOP Instances in a send job have status
success then the job is marked as complete.
Refused
Out of Resources
A700A7FF
The Association is released using A-RELEASE
and the send job is marked as failed. The status
meaning is logged and the job failure is reported to
the user via the job control application. This is a
transient failure.
Error
Data Set does not
match SOP Class
A900A9FF
The Association is released using A-RELEASE
and the send job is marked as failed. The status
meaning is logged and the job failure is reported to
the user via the job control application.
Error
Cannot
Understand
C000CFFF
The Association is released using A-RELEASE
and the send job is marked as failed. The status
meaning is logged and the job failure is reported to
the user via the job control application.
Warning
Coercion of Data
Elements
B000
Image transmission is considered successful but
the status meaning is logged.
Warning
Elements
Discarded
B006
Image transmission is considered successful but
the status meaning is logged.
Warning
Data Set does not
match SOP Class
B007
Image transmission is considered successful. The
status meaning is logged and the job warning is
reported to the user via the job control application.
*
*
Any other
status
code.
The Association is released using A-RELEASE
and the send job is marked as failed. The status
code is logged and the job failure is reported to the
user via the job control application.
All Image Storage SOP Classes supported by the Storage AE exhibit the same behaviour, except where
stated, and are described together in this section.
Table 2.2-7
STORAGE C-STORE RESPONSE STATUS HANDLING BEHAVIOR
S517-E102A
20
The behaviour of Storage AE during communication failure is summarized in the Table below:
Exception
Behavior
Timeout
The Association is released using A-RELEASE and the
send job is marked as failed. The reason is logged and the
job failure is reported to the user via the job control
application.
Association aborted by the SCP
or network layers
The send job is marked as failed The reason is logged and
the job failure is reported to the user via the job control
application.
Table 2.2-8
STORAGE COMMUNICATION FAILURE BEHAVIOR
A failed send job can be restarted by user interaction.
The contents of each Image Storage SOP Instances created by the SDR-120 conform to the DICOM
Image IOD definition and are described in Annex A of this document.
S517-E102A
21
2.2.2. Workflow Application Entity Specification
SOP Class Name
SOP Class UID
SCU
SCP
Modality Worklist
Information Model
- FIND
1.2.840.10008.5.1.4.31
Yes
No
Modality Performed
Procedure Step
1.2.840.10008.3.1.2.3.3
Yes
No
Application Context Name
1.2.840.10008.3.1.1.1
Maximum number of simultaneous Associations
1
Maximum number of outstanding asynchronous
transactions
1
2.2.2.1. SOP Classes
The SDR-120 provides Standard Conformance to the following SOP Classes:
Table 2.2-9
SOP CLASSES SUPPORTED FOR AE WORKFLOW
2.2.2.2. Association Policies
2.2.2.2.1. General
The DICOM standard application context name for DICOM 3.0 is always proposed:
Table 2.2-10
DICOM APPLICATION CONTEXT FOR AE WORKFLOW
2.2.2.2.2. Number of Associations
The SDR-120 initiates one Association at a time for Worklist request.
NUMBER OF ASSOCIATIONS INITIATED FOR AE WORKFLOW
2.2.2.2.3. Asynchronous Nature
The SDR-120 does not support asynchronous communication (multiple outstanding transactions over a
single Association).
ASYNCHRONOUS NATURE AS A SCU FOR AE WORKFLOW
Table 2.2-11
Table 2.2-12
S517-E102A
22
2.2.2.2.4. Implementation Identifying Information
Implementation Class UID
1.2.392.200036.9110.1.0.6711.2001002
Implementation Version Name
SPF XX (XX : version number)
The implementation information for this Application Entity is:
Table 2.2-13
DICOM IMPLEMENTATION CLASS AND VERSION FOR AE WORKFLOW
2.2.2.3. Association Initiation Policy
2.2.2.3.1. Activity – Worklist Update
2.2.2.3.1.1. Description and Sequencing of Activities
The request for a Worklist Update is initiated by user interaction, i.e. pressing the buttons “Update”
/ ”Query” or automatically triggered by specific operation. With “Update” the automated query
mechanism is performed immediately on request, while with “Query” a dialog to enter search criteria is
opened an interactive query can be performed.
The interactive Patient Worklist Query will display a dialog for entering data as search criteria. When
the Query is started on user request, only the data from the dialog will be inserted as matching keys into
the query.
Upon initiation of the request, the SDR-120 will build an Identifier for the C-FIND request, will initiate
an Association to send the request and will wait for Worklist responses. After retrieval of all responses,
the SDR-120 will access the local database to add or update patient demographic data. To protect the
system from overflow, the SDR-120 will limit the number of processed worklist responses to a
configurable maximum. During receiving the worklist response items are counted and the query
processing is canceled by issuing a C-FIND-CANCEL if the configurable limit of items is reached.
The SDR-120 will initiate an Association in order to issue a C-FIND request according to the Modality
Worklist Information Model.
S517-E102A
23
Workflow
AE
Department
Scheduler
1. Open Association
2. C-FIND Request (WorklistQuery)
3. C-FIND Response (WorklistItem) – Status=Pending
6. Close Association
4. C-FIND Response (WorklistItem) – Status=Pending
5. C-FIND Response – Status=Success
7. Select Worklist item
Workflow
AE
Department
Scheduler
1. Open Association
2. C-FIND Request (WorklistQuery)
3. C-FIND Response (WorklistItem) – Status=Pending
6. Close Association
4. C-FIND Response (WorklistItem) – Status=Pending
5. C-FIND Response – Status=Success
7. Select Worklist item
Figure 2.2-2 SEQUENCE OF ACTIVITY – WORKLIST UPDATE
A possible sequence of interactions between the Workflow AE and a Department Scheduler (e.g. a
device such as a RIS or HIS which supports the Modality Worklist SOP Class as an SCP) is illustrated
in Figure above:
1. The Worklist AE opens an association with the Department Scheduler.
2. The Worklist AE sends a C-FIND request to the Department Scheduler containing the Worklist
Query attributes.
3. The Department Scheduler returns a C-FIND response containing the requested attributes of the
first matching Worklist Item.
4. The Department Scheduler returns another C-FIND response containing the requested attributes
of the second matching Worklist Item.
5. The Department Scheduler returns another C-FIND response with status Success indicating that
no further matching Worklist Items exist. This example assumes that only 2 Worklist items
match the Worklist Query.
6. The Worklist AE closes the association with the Department Scheduler.
7. The user selects a Worklist Item from the Worklist and prepares to acquire new images.
S517-E102A
24
2.2.2.3.1.2. Proposed Presentation Contexts
Presentation Context Table
Abstract Syntax
Transfer Syntax
Role
Ext.
Neg.
Name
UID
Name
UID
Modality Worklist
Information Model –
FIND
1.2.840.10008.5.1
.4.31
Implicit VR Little Endian
Explicit VR Little Endian
Explicit VR Big Endian
1.2.840.10008.1.2
1.2.840.10008.1.2.1
1.2.840.10008.1.2.2
SCU
None
Service
Status
Further
Meaning
Error
Code
Behavior
Success
Matching is
complete
0000
The SCP has completed the matches. Worklist
items are available for display or further
processing.
Refused
Out of Resources
A700
The Association is released using A-RELEASE
and the worklist query is marked as failed. The
status meaning is logged and reported to the user if
an interactive query. Any additional error
information in the Response will be logged.
Failed
Identifier does
not match SOP
Class
A900
The Association is released using A-RELEASE
and the worklist query is marked as failed. The
status meaning is logged and reported to the user if
an interactive query. Any additional error
information in the Response will be logged.
Failed
Unable to
Process
C000-CFFF
The Association is released using A-RELEASE
and the worklist query is marked as failed. The
status meaning is logged and reported to the user if
an interactive query. Any additional error
information in the Response will be logged.
The SDR-120 will propose Presentation Contexts as shown in the following table:
Table 2.2-14
PROPOSED PRESENTATION CONTEXTS FOR WORKLIST UPDATE
2.2.2.3.1.3. SOP Specific Conformance for Modality Worklist
The behavior of the SDR-120 when encountering status codes in a Modality Worklist C-FIND response
is summarized in the Table below. If any other SCP response status than “Success” or “Pending” is
received by the SDR-120, an error message will appear on the user interface.
Table 2.2-15
MODALITY WORKLIST C-FIND RESPONSE STATUS HANDLING BEHAVIOR
S517-E102A
25
Service
Status
Further
Meaning
Error
Code
Behavior
Cancel
Matching
terminated due to
Cancel request
FE00
If the query was cancelled due to too many
worklist items then the SCP has completed the
matches. Worklist items are available for display
or further processing. Otherwise, the Association
is released using A-RELEASE and the worklist
query is marked as failed. The status meaning is
logged and reported to the user if an interactive
query.
Pending
Matches are
continuing
FF00
The worklist item contained in the Identifier is
collected for later display or further processing.
Pending
Matches are
continuing –
Warning that one
or more Optional
Keys were not
supported
FF01
The worklist item contained in the Identifier is
collected for later display or further processing.
The status meaning is logged only once for each CFIND operation.
*
*
Any other
status code.
The Association is released using A-RELEASE
and the worklist is marked as failed. The status
meaning is logged and reported to the user if an
interactive query. Any additional error information
in the Response will be logged.
Exception
Behavior
Timeout
The Association is released using A-RELEASE and the
worklist query is marked as failed. The reason is logged
and reported to the user if an interactive query.
Association aborted by the SCP
or network layers
The worklist query is marked as failed The reason is
logged and reported to the user if an interactive query.
The behaviour of the SDR-120 during communication failure is summarized in the Table below.
MODALITY WORKLIST COMMUNICATION FAILURE BEHAVIOR
Acquired images will always use the Study Instance UID specified for the Scheduled Procedure Step (if
available). If an acquisition is unscheduled, a Study Instance UID will be generated locally.
S517-E102A
Table 2.2-16
26
The Table below provides a description of the SDR-120 Worklist Request Identifier and specifies the
Module Name
Attribute Name
Tag
VR M R Q D
IOD
SOP Common
Specific Character Set
(0008,0005)
CS S
Scheduled Procedure Step
Scheduled Procedure Step Sequence
(0040,0100)
SQ x > Modality
(0008,0060)
CS S x
> Requested Contrast Agent
(0032,1070)
LO > Scheduled Station AE Title
(0040,0001)
AE S x x > Scheduled Procedure Step Start Date
(0040,0002)
DA R x x
> Scheduled Procedure Step Start Time
(0040,0003)
TM R x x
> Scheduled Performing Physician’s Name
(0040,0006)
PN x > Scheduled Procedure Step Description
(0040,0007)
LO x > Scheduled Protocol Code Sequence
(0040,0008)
SQ x > Code Value
(0008,0100)
CS x > Coding Scheme Designator
(0008,0102)
SH x > Coding Scheme Version
(0008,0103)
SH x > Code Meaning
(0008,0104)
LO x > Scheduled Procedure Step ID
(0040,0009)
SH x > Scheduled Station Name
(0040,0010)
SH x Requested Procedure
Referenced Study Sequence
(0008,1110)
SQ x > Referenced SOP Class UID
(0008,1150)
UI x > Referenced SOP Instance UID
(0008,1155)
UI x Study Instance UID
(0020,000D)
UI x
Requested Procedure Description
(0032,1060)
LO x Requested Procedure Code Sequence
(0032,1064)
SQ x > Code Value
(0008,0100)
CS x > Coding Scheme Designator
(0008,0102)
SH x > Coding Scheme Version
(0008,0103)
SH x
> Code Meaning
(0008,0104)
LO x Requested Procedure ID
(0040,1001)
SH x x
attributes that are copied into the images. Unexpected attributes returned in a C-FIND response are
ignored.
Requested return attributes not supported by the SCP are set to have no value. Non-matching responses
returned by the SCP due to unsupported optional matching keys are ignored.
Table 2.2-17
WORKLIST REQUEST IDENTIFIER
S517-E102A
Loading...