DICOM ULTASOUND CONFERENCE VOLUSON-E10-E8-E6 REV2 PDF PDF
DICOM ULTASOUND CONFERENCE VOLUSON-E10-E8-E6 REV2 PDF PDF
DICOM ULTASOUND CONFERENCE VOLUSON-E10-E8-E6 REV2 PDF PDF
DICOM
Conformance Statement
DOC1992311
Revision 2
The Voluson E6/E8/E10 is a self-contained networked computer system used for acquiring
ultrasound diagnostic medical images. The system implements the necessary DICOM services
to download work list from an information system, save acquired US images to a network
storage device or media, print to a networked hardcopy device, query and move US images
from a networked storage and inform the information system about the work actually done.
The system conforms to the DICOM standard to allow the sharing of medical information with
other digital imaging systems.
3
Table 0.0–1: Provides an overview of the network services supported by
Voluson E6/E8/E10.
User of Service Provider of Service
SOP Classes
(SCU) (SCP)
Transfer
Verification Yes Yes
Yes
US Image Storage Yes
(only in context of Q/R)
Yes
US Multi-frame Storage Yes
(only in context of Q/R)
Enhanced US Volume
Yes No
Storage
Secondary Capture Image Yes
Yes
Storage (only in context of Q/R)
Query/Retrieve
Study Root Q/R - Find Yes No
Study Root Q/R - Move Yes No
Print Management
Basic Grayscale Print
Yes No
Management
Basic Color Print
Yes No
Management
Workflow Management
Modality Worklist Yes No
Modality Performed
Yes No
Procedure
Storage Commitment Push
Yes No
Model
Notes, Report, Measurements, Transfer
Comprehensive SR
Yes No
Storage
4
Contents
Contents i
1 Introduction 1
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Overall DICOM Conformance Statement Document Structure . . . . . . . . . . . 2
1.3 Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Scope and Field of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Important Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
i
4 Ultrasound (US) Information Object Implementation 27
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 US IOD Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 US Entity-Relationship Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.1 Entity Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.2 Voluson E6/E8/E10 Mapping of DICOM Entities . . . . . . . . . . . . . . 27
4.4 IOD Module Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.5 Information Module Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5.1 Common Patient Entity Modules . . . . . . . . . . . . . . . . . . . . . . . 28
4.5.2 Common Study Entity Modules . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5.3 Common Series Entity Modules . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.4 Common Equipment Entity Modules . . . . . . . . . . . . . . . . . . . . . 31
4.5.5 Common Image Entity Modules . . . . . . . . . . . . . . . . . . . . . . . 31
4.5.6 General Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.7 General Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
ii
7 SC Information Object Implementation 48
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.2 SC IOD Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.3 SC Entity-Relationship Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.3.1 Entity Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.3.2 Voluson E6/E8/E10 Mapping of DICOM Entities . . . . . . . . . . . . . . 48
7.4 IOD Module Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.5 Information Module Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.5.1 SC Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
iii
10 Modality Performed Procedure Step SOP Class Definition 65
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
10.2 Modality Performed Procedure Step SOP Class Definition . . . . . . . . . . . . . 65
10.2.1 IOD Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
10.2.2 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
iv
14 Audit Trail Message Format Profile 85
14.1 Supported Audit Message list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
14.2 Audit Message Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
14.2.1 Application Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
14.2.2 Begin Transferring DICOM Instances . . . . . . . . . . . . . . . . . . . . 86
14.2.3 Data Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
14.2.4 Data Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
14.2.5 DICOM Instances Accessed . . . . . . . . . . . . . . . . . . . . . . . . . . 89
14.2.6 DICOM Instances Transferred . . . . . . . . . . . . . . . . . . . . . . . . 90
14.2.7 DICOM Study Deleted . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
14.2.8 Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
14.2.9 User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
15 Known Limitations 97
v
1 Introduction
1.1 Overview
Section 1 (Introduction), which describes the overall structure, intent, and references
for this Conformance Statement
1
section 13 (study root query/retrieve information model), which specifies the
Voluson E6/E8/E10 compliance to dicom requirements for the study root query/retrieve
information model.
section 14 (audit trail message format profile), which specifies the Voluson E6/E8/E10
compliance to dicom requirements for the audit trail message format profile.
The Documentation Structure of the GE Healthcare Conformance Statements and their rela-
tionship with the DICOM Conformance Statements is shown below.
This document specifies the DICOM implementation. It is entitled:
This DICOM Conformance Statement documents the DICOM Conformance Statement and
Technical Specification required to inter-operate with the Voluson E6/E8/E10 network interface.
Introductory information, which is applicable to all GE Healthcare Conformance Statements,
is described in the document:
Introduction to the Integrated DICOM/Network v3.0 (ID/Net v3.0) Conformance Statement
Direction: 2118780.
This Introduction familiarizes the reader with DICOM terminology and general concepts. It
should be read prior to reading the individual products’ GE Healthcare Conformance State-
ments.
The Voluson E6/E8/E10 Conformance Statement, contained in this document, also specifies
the Lower Layer communications, which it supports (e.g. TCP/IP). However, the Technical
Specifications are defined in the DICOM Part 8 standard.
For more information including Network Architecture and basic DICOM concepts, please refer
to the Introduction.
For more information regarding DICOM, copies of the Standard may be obtained on the Internet
at http://medical.nema.org. Comments on the standard may be addressed to:
DICOM Secretariat NEMA 1300 N. 17th Street, Suite 1847 Rosslyn, VA 22209 USA
The reader of this document is concerned with software design and/or system integration issues.
It is assumed that the reader of this document is familiar with the DICOM Standards and with
the terminology and concepts, which are used in those Standards. If readers are unfamiliar
with DICOM terminology they should first refer to the document listed below, then read the
DICOM Standard itself, prior to reading this DICOM Conformance Statement document.
2
1.4 Scope and Field of Application
It is the intent of this document, in conjunction with the Introduction to the Integrated DI-
COM/Network v3.0 (ID/Net v3.0) Conformance Statement, Direction: 2118780, to provide
an unambiguous specification for GE Healthcare implementations. This specification, called a
Conformance Statement, includes a DICOM Conformance Statement and is necessary to ensure
proper processing and interpretation of GE Healthcare medical data exchanged using DICOM.
The Voluson E6/E8/E10 Conformance Statements are available to the public.
Included in this DICOM Conformance Statement are the Module Definitions, which define
all data elements, used by the Voluson E6/E8/E10 implementation. If the user encounters
unspecified private data elements while parsing a Voluson E6/E8/E10 Data Set, the user is well
advised to ignore those data elements (per the DICOM standard). Unspecified private data
element information is subject to change without notice. If, however, the device is acting as a
”full fidelity storage device”, it should retain and re-transmit all of the private data elements
which are sent by the Voluson E6/E8/E10.
The use of these DICOM Conformance Statements, in conjunction with the DICOM Standards,
is intended to facilitate communication with the Voluson E6/E8/E10 equipment. However, by
itself, it is not sufficient to ensure that inter-operation will be successful. The user
(or user’s agent) needs to proceed with caution and address at least four issues:
Validation - Testing the complete range of possible interactions between any GE de-
vice and non-GE devices, before the connection is declared operational, should not be
overlooked. Therefore, the user should ensure that any non-GE provider accepts full re-
sponsibility for all validation required for their connection with GE devices. This includes
the accuracy of the image data once it has crossed the interface between the GE imaging
equipment and the non-GE device and the stability of the image data for the intended
applications.
Such a validation is required before any clinical use (diagnosis and/or treatment) is per-
formed. It applies when images acquired on GE imaging equipment are processed/displayed
on a non-GE device, as well as when images acquired on non-GE equipment is pro-
cessed/displayed on a GE console or workstation.
Future Evolution - GE understands that the DICOM Standard will evolve to meet the
user’s growing requirements. GE is actively involved in the development of the DICOM
Standard. DICOM will incorporate new features and technologies and GE may follow
the evolution of the Standard. The GE Healthcare protocol is based on DICOM as
specified in each DICOM Conformance Statement. Evolution of the Standard may require
3
changes to devices, which have implemented DICOM. In addition, GE reserves the right to
discontinue or make changes to the support of communications features (on its products)
reflected on by these DICOM Conformance Statements. The user should ensure that any
non-GE provider, which connects with GE devices, also plans for the future evolution of
the DICOM Standard. Failure to do so will likely result in the loss of function and/or
connectivity as the DICOM Standard changes and GE Products are enhanced to support
these changes.
Interaction - It is the sole responsibility of the non-GE provider to ensure that com-
munication with the interfaced equipment does not cause degradation of GE imaging
equipment performance and/or function.
4
2 Network Conformance Statement
2.1 Introduction
This section of the DICOM Conformance Statement specifies the compliance to DICOM con-
formance requirements for the relevant Networking features for the Voluson E6/E8/E10. Note
that the format of this section strictly follows the format defined in DICOM Standard PS 3.2
(Conformance). Please refer to that part of the standard while reading this section. Voluson
E6/E8/E10 is an Ultrasound scanner running on a commercial computer. It allows for the
following DICOM functionality:
• Sending and receiving Echo messages to and from DICOM Verification SCP and client.
• Sending start and end of examination to a DICOM Modality Performed Procedure Step
SCP.
• Sending storage commitment requests to and receiving replies from a DICOM Storage
Commitment SCP.
The Basic and Specific Application models for this device are shown in Figure 1.
There are seven local real-world activities that occur in Voluson E6/E8/E10 - Image Send,
Verify, Query Worklist, Start/End Exam, Print Image, Query/Retrieve and Re-
ceive Image.
• Image Send spools images or SR documents into a send queue. The queue manager then
initiates a connection with the DICOM SCP and transmits the images and SR documents
to the DICOM SCP. If Storage Commitment is configured, a commitment request will be
sent for the images and SR documents. The resulting N-Event-Report from the SCP will
be processed by the queue manager.
• Verify initiates a connection with the DICOM SCP, posts a Verification request and
closes the connection. It also responds to incoming Verification requests.
• Query Worklist initiates a connection with the DICOM SCP, performs a query and
retrieves the matching entries to the product.
5
Figure 1: Application Data Flow Diagram
6
• Print Image will send images to a DICOM Print SCP. It uses the same spooling mech-
anism as Image Send.
• Query/Retrieve will send queries to a DICOM Query/Retrieve SCP and retrieve images.
• Receive Image: The modality will accept requests for DICOM image storage and store
the received images into a local database.
• Responds to replies from DICOM Storage Commitment SCPs, for storage commitment
requests of images and SR documents sent by Voluson E6/E8/E10.
Not applicable.
7
2.3 AE Specifications
This Application Entity provides Standard Conformance to the following DICOM SOP Classes
as an SCU:
Table 2.3–1: SCU SOP Classes
This Application Entity provides Standard Conformance to the following DICOM SOP Classes
as an SCP:
Table 2.3–2: SCP SOP Classes
2.3.1.1.1 General
The DICOM Application Context Name (ACN), which is always proposed, is:
Name UID
Application Context Name 1.2.840.10008.3.1.1.1
8
The Maximum Length PDU negotiation is included in all association establishment requests.
The maximum length PDU for an association initiated by the equipment is:
Name Length
Maximum PDU Size Offered (not configurable) 28872 bytes
• Version Name
”1.2.276.0.26.20010718.240”
”KRETZDICOM 240”
Note: The Implementation Version Name may change in the future without modification of this
document.
The Voluson E6/E8/E10 AE attempts to establish a new association with a remote device due
to the following Real-World Activities:
• Image Send initiated by the operator for images and SR documents and sending requests
for Storage Commitment.
9
• Verification, which verifies application level communication between peer DICOM AE’s
for service purposes.
Upon a request by the operator (manual or automatic), images or SR documents will be sent
to a DICOM Storage SCP.
The Proposed Presentation Context Table depends on compression according to the following
tables:
Table 2.3–5: Presentation Context Table - Proposed (No Compression)
Abstract Abstract Syntax UID Transfer Transfer Syntax UID Role Ext.
Syntax Syntax Name Neg.
Name
Secondary 1.2.840.10008.5.1.4.1.1.7 Explicit VR 1.2.840.10008.1.2.1 SCU None.
Capture Little Endian
Image Explicit VR 1.2.840.10008.1.2.2
Storage Big Endian
Implicit VR 1.2.840.10008.1.2
Little Endian
Ultrasound 1.2.840.10008.5.1.4.1.1.6.1 Explicit VR 1.2.840.10008.1.2.1 SCU None.
Image Little Endian
Storage Explicit VR 1.2.840.10008.1.2.2
Big Endian
Implicit VR 1.2.840.10008.1.2
Little Endian
Enhanced 1.2.840.10008.5.1.4.1.1.6.2 Explicit VR 1.2.840.10008.1.2.1 SCU None.
US Volume Little Endian
Storage Explicit VR 1.2.840.10008.1.2.2
Big Endian
Implicit VR 1.2.840.10008.1.2
Little Endian
Ultrasound 1.2.840.10008.5.1.4.1.1.3.1 Explicit VR 1.2.840.10008.1.2.1 SCU None.
Multi-Frame Little Endian
Image Explicit VR 1.2.840.10008.1.2.2
Storage Big Endian
Implicit VR 1.2.840.10008.1.2
Little Endian
10
Table 2.3–6: Presentation Context Table - Proposed (JPEG Compression)
Abstract Abstract Syntax UID Transfer Transfer Syntax UID Role Ext.
Syntax Syntax Name Neg.
Name
Secondary 1.2.840.10008.5.1.4.1.1.7 JPEG Baseline 1.2.840.10008.1.2.4.50 SCU None.
Capture JPEG Lossless 1.2.840.10008.1.2.4.70
Image Non-Hier.
Storage (Process 14)
Ultrasound 1.2.840.10008.5.1.4.1.1.6.1 JPEG Baseline 1.2.840.10008.1.2.4.50 SCU None.
Image JPEG Lossless 1.2.840.10008.1.2.4.70
Storage Non-Hier.
(Process 14)
Enhanced 1.2.840.10008.5.1.4.1.1.6.2 JPEG Baseline 1.2.840.10008.1.2.4.50 SCU None.
US Volume JPEG Lossless 1.2.840.10008.1.2.4.70
Storage Non-Hier.
(Process 14)
Ultrasound 1.2.840.10008.5.1.4.1.1.3.1 JPEG Baseline 1.2.840.10008.1.2.4.50 SCU None.
Multi-Frame JPEG Lossless 1.2.840.10008.1.2.4.70
Image Non-Hier.
Storage (Process 14)
Abstract Abstract Syntax UID Transfer Transfer Syntax UID Role Ext.
Syntax Syntax Name Neg.
Name
Compre- 1.2.840.10008.5.1.4.1 Explicit VR 1.2.840.10008.1.2.1 SCU None.
hensive .1.88.33 Little Endian
Structured Explicit VR 1.2.840.10008.1.2.2
Report Big Endian
Implicit VR 1.2.840.10008.1.2
Little Endian
Abstract Abstract Syntax UID Transfer Transfer Syntax UID Role Ext.
Syntax Syntax Name Neg.
Name
Storage 1.2.840.10008.1.20.1 Explicit VR 1.2.840.10008.1.2.1 SCU None.
Commitment Little Endian
Push Model Explicit VR 1.2.840.10008.1.2.2
SOP Class Big Endian
Implicit VR 1.2.840.10008.1.2
Little Endian
11
2.3.1.2.1.2.1 SOP Specific DICOM Conformance for all Storage SOP Classes
The Voluson E6/E8/E10 also sends a Storage Commitment Request, with the above proposed
presentation context. The result from the SCP is expected on another association for the
Storage Commitment result.
2.3.1.2.1.2.2 SOP Specific DICOM Statement for all Storage SOP Classes and
Storage Commitment SOP Class
For this SOP class, all status codes with status Refused or Error are treated as failures and will
terminate the association and operation. On a failure, the request will remain in the sending
queue and will be retried a configurable amount of times. If the failure persists the job will be
marked as permanently failed. Jobs with status permanently failed can be retried manually.
Warning or Success are treated as successes. There is no fallback procedure available if the SCP
does not support the Enhanced US Volume Storage SOP Class.
The Storage Commitment SCP AE Title and the Storage SCP AE Title are free configurable
and can be different.
The user may initiate a DICOM Verification Request in the Config screen. Associations will be
released upon the receipt of each C-ECHO confirmation. In the event that the SCP does not
respond for some reason, the operation will time out and the Voluson E6/E8/E10 will close the
association.
Abstract Abstract Syntax UID Transfer Transfer Syntax UID Role Ext.
Syntax Syntax Name Neg.
Name
Verification 1.2.840.10008.1.1 Explicit VR 1.2.840.10008.1.2.1 SCU None.
SOP Class Little Endian
Explicit VR 1.2.840.10008.1.2.2
Big Endian
Implicit VR 1.2.840.10008.1.2
Little Endian
The user may initiate a DICOM Worklist Query in Search screen, which will send a C-FIND-RQ
to the Worklist SCP.
12
Associations will be released upon the receipt of C-FIND-RSP confirmation.
C-FIND-CANCEL-RQ is not supported.
Abstract Abstract Syntax UID Transfer Transfer Syntax UID Role Ext.
Syntax Syntax Name Neg.
Name
Modality 1.2.840.10008.5.1.4.31 Explicit VR 1.2.840.10008.1.2.1 SCU None.
Worklist Little Endian
Information Explicit VR 1.2.840.10008.1.2.2
Model - Big Endian
FIND Implicit VR 1.2.840.10008.1.2
Little Endian
The Voluson E6/E8/E10 includes matching keys in the Modality Worklist queries as described in
Section 9.5. Status codes Refused, Error and Warning are treated as failures and will terminate
the association and operation. On a failure, the user will be informed. On status code Success
the worklist will be displayed and the operation will be terminated. On Status code Pending
the system will continue receiving C-FIND-RSP’s.
The Modality Performed Procedure Step message is sent when the exam is started by the user
after a worklist entry has been selected or patient data have been entered on the patient data
entry screen. Also different procedure steps can be selected at the patient data entry screen.
At this time the N-CREATE message is sent.
The N-SET will be sent when ’End Exam’ is being pressed. The status is set to COMPLETED
by default. However the operator may choose to manually set the status to DISCONTINUED
and select the discontinuation reason from a predefined list.
The sequences and codes for N-CREATE and N-SET are described in Tables 10.2–2, 10.2–3
and 10.2–4.
13
Table 2.3–11: Presentation Context Table - Proposed
Abstract Abstract Syntax UID Transfer Transfer Syntax UID Role Ext.
Syntax Syntax Name Neg.
Name
Modality 1.2.840.10008.3.1.2.3.3 Explicit VR 1.2.840.10008.1.2.1 SCU None.
Performed Little Endian
Procedure Explicit VR 1.2.840.10008.1.2.2
Step SOP Big Endian
Class Implicit VR 1.2.840.10008.1.2
Little Endian
The Voluson E6/E8/E10 includes Attributes in the Modality Performed Procedure Step N-
CREATE as described in Section 10.2.1.
The Voluson E6/E8/E10 includes Attributes in the Modality Performed Procedure Step N-SET
as described in Section 10.2.1.
The mapping from Worklist attributes is described in Section 9.5.
Voluson E6/E8/E10 sends N-SET after the exam is ended. The N-SET will include all acquired
images SOP Instance UIDs and the status of COMPLETED or DISCONTINUED.
For this SOP class, all status codes with status Refused or Error are treated as failures and
terminate the association and operation. All status codes with status Warning or Success are
treated as successes.
Upon a request by the operator, print jobs will be sent to a DICOM Print SCP. The jobs are
entered into a send queue and processed by the spool manager. If an error occurs during the
transmission the operation may be retried automatically. The number of automatic retries is
configurable. After the automatic retries the operation can be manually retried.
Abstract Abstract Syntax UID Transfer Transfer Syntax UID Role Ext.
Syntax Syntax Name Neg.
Name
Basic 1.2.840.10008.5.1.1.9 Explicit VR 1.2.840.10008.1.2.1 SCU None.
Grayscale Little Endian
Print Explicit VR 1.2.840.10008.1.2.2
Management Big Endian
Meta SOP Implicit VR 1.2.840.10008.1.2
Class Little Endian
14
Table 2.3–12: Presentation Context Table - Proposed (continued)
Abstract Abstract Syntax UID Transfer Transfer Syntax UID Role Ext.
Syntax Syntax Name Neg.
Name
Basic Color 1.2.840.10008.5.1.1.18 Explicit VR 1.2.840.10008.1.2.1 SCU None.
Print Little Endian
Management Explicit VR 1.2.840.10008.1.2.2
Meta SOP Big Endian
Class Implicit VR 1.2.840.10008.1.2
Little Endian
The Voluson E6/E8/E10 treats all status codes with status Refused or Error as failures and the
spool manager retries the operation. After the configurable number of retries has been exceeded
the spooler’s job status is set to FAILED and the print job may be retried manually. Detailed
information is described in Section 12. All status codes with status Warning or Success are
treated as success.
The user may initiate a DICOM Query in Search screen, which will send a C-FIND-RQ to the
Query/Retrieve SCP.
Associations will be released upon the receipt of C-FIND-RSP confirmation.
The user may then select an examination to be retrieved, using the C-MOVE-RQ command to
the Query/Retrieve SCP. The result from the SCP is expected on another association for the
retrieved examinations.
Abstract Abstract Syntax UID Transfer Transfer Syntax UID Role Ext.
Syntax Syntax Name Neg.
Name
Study Root 1.2.840.10008.5.1.4.1.2.2.1 Explicit VR 1.2.840.10008.1.2.1 SCU None.
Query/ Little Endian
Retrieve Explicit VR 1.2.840.10008.1.2.2
Information Big Endian
Model - Implicit VR 1.2.840.10008.1.2
FIND Little Endian
Study Root 1.2.840.10008.5.1.4.1.2.2.2 Explicit VR 1.2.840.10008.1.2.1 SCU None.
Query/ Little Endian
Retrieve Explicit VR 1.2.840.10008.1.2.2
Information Big Endian
Model - Implicit VR 1.2.840.10008.1.2
MOVE Little Endian
15
2.3.1.2.6.2.1 SOP Specific DICOM Conformance Statement for Query/Retrieve
SOP Class
Types of Matching:
16
• Wildcard Matching (*)
The types of Matching supported by the C-FIND SCU are: ‘S’ indicates the identifier attribute
uses Single Value Matching, an ‘R’ indicates Range Matching, a ”*” indicates wildcard matching,
a ‘U’ indicates Universal Matching, and ‘UNIQUE’ indicates that this is the Unique Key for
that query level, in which case Universal Matching or Single Value Matching is used depending
on the query level.
”Filtering is supported” means that matching strings can be controlled from the Search screen.
C-CANCEL-FIND-RQ and C-CANCEL-MOVE-RQ are not supported.
The Voluson E6/E8/E10 treats all status codes with status Refused or Error as failures. All
status codes with status Warning or Success are treated as successes. On Status Code Pending
the system will continue receiving C-FIND-RSP’s. The C-MOVE time-out is not configureable.
The Voluson E6/E8/E10 AE accepts an association when it receives a Verification Request from
another network device, an image storage request from an SCU or a Storage Commitment result
from a Storage Commitment SCP.
An incoming Verification Request will cause the AE to accept the association and respond with
a Verification Response.
Abstract Abstract Syntax UID Transfer Transfer Syntax UID Role Ext.
Syntax Syntax Name Neg.
Name
Verification 1.2.840.10008.1.1 Explicit VR 1.2.840.10008.1.2.1 SCP None.
SOP Class Little Endian
Explicit VR 1.2.840.10008.1.2.2
Big Endian
Implicit VR 1.2.840.10008.1.2
Little Endian
17
2.3.1.3.1.2.1 SOP Specific DICOM Conformance Statement for Verify SOP Class
The AE provides standard conformance to the Verification SOP Class as an SCP. The port
number used is configured in Config screen, default is 104.
No criterion.
The selected transfer syntax is based on the proposed transfer syntax list. The priority order
is Explicit VR Little Endian, Explicit VR Big Endian and Implicit VR Little Endian.
Voluson E6/E8/E10 will only listen for an N-EVENT-REPORT (Storage Commitment Result)
from a Storage Commitment SCP in a new association.
Abstract Abstract Syntax UID Transfer Transfer Syntax UID Role Ext.
Syntax Syntax Name Neg.
Name
Storage 1.2.840.10008.1.20.1 Explicit VR 1.2.840.10008.1.2.1 SCU None.
Commitment Little Endian
Push Model Explicit VR 1.2.840.10008.1.2.2
SOP Class Big Endian
Implicit VR 1.2.840.10008.1.2
Little Endian
2.3.1.3.2.2.1 SOP Specific DICOM Conformance Statement for the Storage Com-
mitment Push Model SOP Class SCU
The Voluson E6/E8/E10 will only accept the SCU role (which must be proposed via SCP/SCU
Role Selection Negotiation) within a Presentation Context for the Storage Commitment Push
Model SOP Class. The result from the SCP is expected on another association for the Storage
Commitment result.
The Voluson E6/E8/E10 behavior after receiving an N-EVENT-REPORT-RQ (Storage Com-
mitment Result) is described in Section 11.2.3.2.
18
2.3.1.3.3 Real-World Activity (Receive Image Operation)
Voluson E6/E8/E10 will accept associations for C-STORE-RQs. The received images will be
stored into a local database.
Abstract Abstract Syntax UID Transfer Transfer Syntax UID Role Ext.
Syntax Syntax Name Neg.
Name
Secondary 1.2.840.10008.5.1.4.1.1.7 Explicit VR 1.2.840.10008.1.2.1 SCP None.
Capture Little Endian
Image Explicit VR 1.2.840.10008.1.2.2
Storage Big Endian
Implicit VR 1.2.840.10008.1.2
Little Endian
JPEG Baseline 1.2.840.10008.1.2.4.50
JPEG Lossless 1.2.840.10008.1.2.4.70
Non-Hier.
(Process 14)
Ultrasound 1.2.840.10008.5.1.4.1.1.6.1 Explicit VR 1.2.840.10008.1.2.1 SCP None.
Image Little Endian
Storage Explicit VR 1.2.840.10008.1.2.2
Big Endian
Implicit VR 1.2.840.10008.1.2
Little Endian
JPEG Baseline 1.2.840.10008.1.2.4.50
JPEG Lossless 1.2.840.10008.1.2.4.70
Non-Hier.
(Process 14)
Enhanced 1.2.840.10008.5.1.4.1.1.6.2 Explicit VR 1.2.840.10008.1.2.1 SCP None.
US Volume Little Endian
Storage Explicit VR 1.2.840.10008.1.2.2
Big Endian
Implicit VR 1.2.840.10008.1.2
Little Endian
JPEG Baseline 1.2.840.10008.1.2.4.50
JPEG Lossless 1.2.840.10008.1.2.4.70
Non-Hier.
(Process 14)
Ultrasound 1.2.840.10008.5.1.4.1.1.3.1 Explicit VR 1.2.840.10008.1.2.1 SCP None.
Multi-Frame Little Endian
Image Explicit VR 1.2.840.10008.1.2.2
Storage Big Endian
Implicit VR 1.2.840.10008.1.2
Little Endian
JPEG Baseline 1.2.840.10008.1.2.4.50
JPEG Lossless 1.2.840.10008.1.2.4.70
Non-Hier.
(Process 14)
19
2.3.1.3.3.2.1 SOP Specific DICOM Conformance Statement for the Storage SOP
Classes
The AE provides standard conformance to the Storage SOP Classes as an SCP. The port number
used is not configurable and is set to 104.
The SOP Class Extended Negotiation is not supported.
The Storage SOP Class as an SCP is classified as Level 1 (Base).
The following C-Store Response Status values can be returned from the Voluson E6/E8/E10:
No criterion.
The accepted transfer syntaxes are based on the proposed transfer syntax list. The defined
priority order is listed in Table 2.3–19. The first supported transfer syntaxes from Table 2.3–19
will be accepted.
The TCP/IP stack is inherited from the product’s operating system. Please refer to product
documentation for more information.
20
2.4.2.1 API
The Voluson E6/E8/E10 supports DHCP from the product’s operating system. Please refer to
product documentation for more information.
The product will send additional private patient and physition data in private data elements
designated by the private tag 6101,00xx VR LO, VM 1, and 6301, 00xx VR LO, VM 1. Ul-
trasound raw volume data information will be send in private data elements designated by the
private tag 7FE1,00xx VR LO, VM 1 and ultrasound raw data information in private data
elements designated by the private tag 8001,00xx VR LO, VM 1.
2.6 Configuration
The Local AE title is configurable through the Config screen, see below.
Network:
• Local IP address
• Local IP netmask
Local:
• Local AE Title
Verification:
Remote Storage:
21
• The AE Title, IP Address and Port number of the SCP.
• Max retries, Retry interval.
Query/ Retrieve:
• The AE Title, IP Address and Port number of the SCP.
• Default Application.
Modality Worklist:
• The AE Title, IP Address and Port number of the SCP.
Modality Performed Procedure Step:
• The AE Title, IP Address and Port number of the SCP.
Storage Commitment:
• The AE Title, IP Address and Port number of the SCP.
• Max retries, Retry interval.
Print:
• The AE Title, IP Address and Port number of the SCP.
• Max retries, Retry interval.
• Configuration for each print job in setup dialog.
22
2.9.1 Application Level Security
Voluson E6/E8/E10 can be configured to require a password in order to access to the user
interface functionalities.
When an integrity check fails, the connection will be dropped per the TLS protocol, causing
both the sender and the receiver to issue an A-P-ABORT indication to the upper layers with an
implementation-specific provider reason. Currently there are no userdefined provider reasons
implemented.
23
3 Media Storage Conformance
3.1 Introduction
This section of the DICOM Conformance Statement specifies the compliance to DICOM Media
Interchange for the Voluson E6/E8/E10.
Voluson E6/E8/E10 supports the following DICOM functionality:
Voluson E6/E8/E10 is able to export images and structured reports to DICOM media. Browsing
media and reading images or structured reports from DICOM media is not supported.
There is one local real-world activity that occurs in Voluson E6/E8/E10 - Export.
Not applicable.
24
3.3 File Meta Information Options (See PS3.10)
Note: The Implementation Version Name may change in the future without modification of this
document.
3.4 AE Specifications
The Voluson E6/E8/E10 Application Entity provides standard conformance to DICOM Inter-
change Option of the Media Storage Service Class. The Application Profiles and roles are listed
below, the standard profiles are augmented with Secondary Capture images.
3.4.1.1 File Meta Information for the Voluson E6/E8/E10 Application Entity
The Source Application Entity is set from the Voluson E6/E8/E10 local AE title. The local
AE title is configurable.
‘Export’ saves selected DICOM SOP instances to media and creates a DICOM File Set.
For the list of Application Profiles that invoke this AE for ‘Export’ Real-World Activity, see the
Table in Section 3.4.1 where the table describing the profiles and real-world activities is defined.
25
3.4.1.2.1.2 Options
Information Object SOP Class UID Transfer Syntax Transfer Syntax UID
Definition
DICOM Media Storage 1.2.840.10008.1.3.10 Explicit VR Little 1.2.840.10008.1.2.1
Directory Endian
Explicit VR Little 1.2.840.10008.1.2.1
Ultrasound Image Storage 1.2.840.10008.5.1.4.1.1.6.1
Endian
JPEG Baseline 1.2.840.10008.1.2.4.50
Enhanced Ultrasound Explicit VR Little 1.2.840.10008.1.2.1
1.2.840.10008.5.1.4.1.1.6.2
Volume Storage Endian
JPEG Baseline 1.2.840.10008.1.2.4.50
Ultrasound Multi-frame Explicit VR Little 1.2.840.10008.1.2.1
1.2.840.10008.5.1.4.1.1.3.1
Image Storage Endian
JPEG Baseline 1.2.840.10008.1.2.4.50
Secondary Capture Image Explicit VR Little 1.2.840.10008.1.2.1
1.2.840.10008.5.1.4.1.1.7
Storage Endian
JPEG Baseline 1.2.840.10008.1.2.4.50
Comprehensive Structured 1.2.840.10008.5.1.4.1.1.88.33 Explicit VR Little 1.2.840.10008.1.2.1
Report Storage Endian
Voluson E6/E8/E10 creates Secondary Capture Image and Structured Report objects in addi-
tion to the objects defined in the application profiles.
26
4 Ultrasound (US) Information Object Implementation
4.1 Introduction
This section specifies the use of the DICOM US Image IOD to represent the information included
in US images produced by this implementation. Corresponding attributes are conveyed using
the module construct. The contents of this section are:
• IOD Implementation
Please refer to DICOM Standard Part 3 (Information Object Definitions) for a description of
each of the entities contained within the US Information Object.
DICOM Equipment
Patient Patient
Study Exam
Series Exam
Image Image
Curve not used
Within an entity of the DICOM US IOD, attributes are grouped into related set of attributes.
A set of related attributes is termed a module. A module facilitates the understanding of the
semantics concerning the attributes and how the attributes are related with each other. A
module grouping does not infer any encoding of information into data sets.
The table below identifies the defined modules within the entities, which comprise the DICOM
US IOD. Modules are identified by Module Name.
See DICOM Part 3 for a complete definition of the entities, modules, and attributes.
Only the single frame US Image IOD is described here.
27
Table 4.4–1: US Image IOD Modules
Please refer to DICOM Standard Part 3 (Information Object Definitions) for a description of
each of the entities and modules contained within the US Information Object.
The following modules are included to convey Enumerated Values, Defined Terms, and Optional
Attributes supported. Type 1 & Type 2 Attributes are also included for completeness and to
define what values they may take and where these values are obtained. It should be noted
that they are the same ones as defined in the DICOM Standard Part 3 (Information Object
Definitions). The attribute ”Not used” is equal to ”Not present”. Not listed elements are not
supported. For detailed information please also refer to DICOM Standard Part 3 (Information
Object Definitions) Annex C (COMMON COMPOSITE IMAGE IOD MODULES).
Please also refer to DICOM Standard Part 3 (Information Object Definitions) Annex C (IN-
FORMATION MODULE DEFINITIONS).
28
Table 4.5–1: Patient Module Attributes (continued)
29
4.5.2.2 Patient Study Module
30
4.5.4 Common Equipment Entity Modules
31
4.5.5.2 Image Pixel Module
32
Table 4.5–7: VOI LUT Module Attributes (continued)
This Section describes US Series, Equipment, and Image Modules. These Modules contain
attributes that are specific to US Image IOD.
33
Table 4.5–9: US Region Calibration Module elements (continued)
34
4.5.7.2 US Image Module
35
Table 4.5–10: US Image Module Elements (continued)
36
5 Ultrasound Multi-Frame (US-MF) Information Object Im-
plementation
5.1 Introduction
This section specifies the use of the DICOM US Multi-frame Image IOD to represent the infor-
mation included in US images produced by this implementation. Corresponding attributes are
conveyed using the module construct. The contents of this section are:
• IOD Implementation
Please refer to DICOM Standard Part 3 (Information Object Definitions) for a description of
each of the entities contained within the US Multi-Frame Information Object.
DICOM Equipment
Patient Patient
Study Exam
Series Exam
Image Image
Curve not used
Within an entity of the DICOM US Multi-Frame IOD, attributes are grouped into related
set of attributes. A set of related attributes is termed a module. A module facilitates the
understanding of the semantics concerning the attributes and how the attributes are related
with each other. A module grouping does not infer any encoding of information into data sets.
The table below identifies the defined modules within the entities, which comprise the DICOM
US Multi-Frame IOD. Modules are identified by Module Name.
See DICOM Part 3 for a complete definition of the entities, modules, and attributes.
37
Table 5.4–1: US Multi-Frame Image IOD Modules
Please refer to DICOM Standard Part 3 (Information Object Definitions) for a description of
each of the entities and modules contained within the US Multi-Frame Information Object.
The following modules are included to convey Enumerated Values, Defined Terms, and Optional
Attributes supported. Type 1 & Type 2 Attributes are also included for completeness and to
define what values they may take and where these values are obtained. It should be noted
that they are the same ones as defined in the DICOM Standard Part 3 (Information Object
Definitions). The attribute ”Not used” is equal to ”Not present”. Not listed elements are not
supported.
38
Table 5.5–1: Cine Module Elements (continued)
39
6 Enhanced Ultrasound (US) Volume Information Object Im-
plementation (≥ 10.x.x)
6.1 Introduction
This section specifies the use of the DICOM Enhanced US Volume IOD to represent the infor-
mation included in Enhanced US Volumes produced by this implementation. Corresponding
attributes are conveyed using the module construct. The contents of this section are:
• IOD Implementation
Please refer to DICOM Standard Part 3 (Information Object Definitions) for a description of
each of the entities contained within the Enhanced US Volume Information Object.
DICOM Equipment
Patient Patient
Study Exam
Series Exam
Image Image
Curve not used
Within an entity of the DICOM Enhanced US Volume IOD, attributes are grouped into related
set of attributes. A set of related attributes is termed a module. A module facilitates the
understanding of the semantics concerning the attributes and how the attributes are related
with each other. A module grouping does not infer any encoding of information into data sets.
The attribute ”not used” is equal to ”not present”.
The table below identifies the defined modules within the entities, which comprise the DICOM
Enhanced US Volume IOD. Modules are identified by Module Name.
40
See DICOM Part 3 for a complete definition of the entities, modules, and attributes.
Only the Enhanced US Volume IOD is described here.
Some references in the following table may also refer to information contained in the US image
IOD if the contents is identical.
Table 6.4–1: Enhanced US Volume IOD Modules
Please refer to DICOM Standard Part 3 (Information Object Definitions) for a description of
each of the entities and modules contained within the Enhanced US Volume Information Object.
The attribute ”Not used” is equal to ”Not present”. Not listed elements are not supported.
41
6.5.2 Study Entity Modules
42
Table 6.5–3: US Frame Of Reference Module Attributes (continued)
43
6.5.6.2 Image Pixel Module
44
Table 6.5–7: Multi-frame Dimension Module Attributes (continued)
45
Table 6.5–9: Enhanced Palette Color Lookup Table Module Attributes (continued)
46
Table 6.5–10: Enhanced US Image Module Attributes (continued)
47
7 SC Information Object Implementation
7.1 Introduction
This section specifies the use of the DICOM SC Image IOD to represent the information included
in SC images produced by this implementation. Corresponding attributes are conveyed using
the module construct. The contents of this section are:
• IOD Implementation
Please refer to DICOM Standard Part 3 (Information Object Definitions) for a description of
each of the entities contained within the SC Information Object.
DICOM Equipment
Patient Patient
Study Exam
Series Exam
Image Image
Curve not used
Within an entity of the DICOM SC IOD, attributes are grouped into related set of attributes.
A set of related attributes is termed a module. A module facilitates the understanding of the
semantics concerning the attributes and how the attributes are related with each other. A
module grouping does not infer any encoding of information into data sets.
The table below identifies the defined modules within the entities, which comprise the DICOM
SC IOD. Modules are identified by Module Name.
See DICOM Part 3 for a complete definition of the entities, modules, and attributes.
48
Table 7.4–1: SC Image IOD Modules
Please refer to DICOM Standard Part 3 (Information Object Definitions) for a description of
each of the entities and modules contained within the SC Information Object.
The following modules are included to convey Enumerated Values, Defined Terms, and Optional
Attributes supported. Type 1 & Type 2 Attributes are also included for completeness and to
define what values they may take and where these values are obtained. It should be noted
that they are the same ones as defined in the DICOM Standard Part 3 (Information Object
Definitions). The attribute ”Not used” is equal to ”Not present”. Not listed elements are not
supported.
7.5.1 SC Modules
This Module describes equipment used to convert images into a DICOM format.
49
Table 7.5–1: Secondary Capture Equipment Module Attributes (continued)
The table in this Section contains IOD attributes that describe SC images.
50
8 SR Information Object Implementation
8.1 Introduction
This section specifies the use of the DICOM Comprehensive SR IOD to represent the information
included in SC images produced by this implementation. Corresponding attributes are conveyed
using the module construct. The contents of this section are:
• IOD Implementation
Please refer to DICOM Standard Part 3 (Information Object Definitions) for a description of
each of the entities contained within the Comprehensive SR Information Object.
DICOM Equipment
Patient Patient
Study Exam
Series Exam
SR Document Results
Within an entity of the DICOM Comprehensive SR IOD, attributes are grouped into related
set of attributes. A set of related attributes is termed a module. A module facilitates the
understanding of the semantics concerning the attributes and how the attributes are related
with each other. A module grouping does not infer any encoding of information into data sets.
Not listed modules are not supported.
The table below identifies the defined modules within the entities, which comprise the DICOM
Comprehensive SR IOD. Modules are identified by Module Name.
See DICOM Part 3 for a complete definition of the entities, modules, and attributes.
51
Table 8.4–1: SR IOD Modules
Please refer to DICOM Standard Part 3 (Information Object Definitions) for a description of
each of the entities and modules contained within the Comprehensive SR Information Object.
The following modules are included to convey Enumerated Values, Defined Terms, and Optional
Attributes supported. Type 1 & Type 2 Attributes are also included for completeness and to
define what values they may take and where these values are obtained. It should be noted
that they are the same ones as defined in the DICOM Standard Part 3 (Information Object
Definitions).
Not listed elements are not supported.
52
Table 8.5–2: SR Document General Module Attributes (continued)
53
Table 8.5–2: SR Document General Module Attributes (continued)
The equipment supports the following root Templates for SR SOP Instances created, processed,
or displayed by the equipment.
54
8.6 Standard Extended and Private Context Groups and Templates
Due to compatibility reasons some codes in the following tables still using Coding Scheme
Designator ”GEK”. Via application user interface the Coding Scheme Designator ”GEK” can
be changed to the DICOM compliant Coding Scheme Designator ”99GEK”.
All needed context items which are not defined in the DICOM Standard are privately defined
and listed in appendix A.
All needed templates which are not defined in the DICOM Standard are privately defined and
listed in appendix B.
55
9 Modality Worklist Information Model Definition
9.1 Introduction
This section specifies the use of the DICOM Modality Worklist Information Model used to
organize data and against which a Modality Worklist Query will be performed. The contents
of this section are:
This section defines the implementation of the Modality Worklist Information Model.
Please refer to DICOM Standard Part 3 (Information Object Definitions) for a description of
each of the entities contained within the Modality Worklist Information Model .
Schedule Procedure Step is implemented in a basic form to allow the user to retrieve a subset
of attributes.
Requested Procedure is implemented in a basic form to allow the user to retrieve a subset of
attributes.
Imaging Servie Request is implemented in a basic form to allow the user to retrieve a subset of
attributes.
Visit Entity is implemented in a basic form to allow the user to retrieve a subset of attributes.
56
9.3.1.5 Patient Entity Description
Patient Entity is implemented in a basic form to allow the user to retrieve a subset of attributes.
DICOM Equipment
Scheduled Procedure Step Not Applicable
Requested Procedure Exam
Imaging Service Request Exam
Visit Not Applicable
Patient Patient
Within an entity of the DICOM Modality Worklist IOD, attributes are grouped into related
set of attributes. A set of related attributes is termed a module. A module facilitates the
understanding of the semantics concerning the attributes and how the attributes are related
with each other. A module grouping does not infer any encoding of information into data sets.
The table below identifies the defined modules within the entities, which comprise the DICOM
Modality Worklist IOD. Modules are identified by Module Name.
See DICOM Part 3 for a complete definition of the entities, modules, and attributes.
57
9.5 Information Model Keys
Please refer to DICOM Standard PS 3.3. (Information Object Definitions) and PS 3.4 (Service
Class Specifications) for a description of each of the Entities contained within the Modality
Worklist Information Model.
The following Module descriptions are included to specify what data elements are supported
and what type of matching can be applied. It should be noted that they are the same ones as
defined in the DICOM Standard PS 3.4 (Service Class Specifications).
The term Instance is used for Images and Reports in examinations, that are based on Worklist
entries.
Not listed elements are not supported.
Following are the types of matching that can be requested by the implementation:
• Range of date.
Fields with ”Filtering supported” in the Matching column can be controlled from the Search
screen.
Fields with ”Matching supported” in the Matching column can be filled in by the Worklist.
58
9.5.2.2 Scheduled Procedure Step Module
59
Table 9.5–2: Scheduled Procedure Step Module Attributes (continued)
60
9.5.3 Requested Procedure Entity
61
Table 9.5–4: Imaging Service Request Module Attributes (continued)
62
9.5.5.3 Visit Relationship
63
Table 9.5–9: Patient Demographic Module Attributes (continued)
64
10 Modality Performed Procedure Step SOP Class Definition
10.1 Introduction
This section of the DICOM Conformance Statement specifies the Modality Performed Procedure
Step SOP Class, the optional attributes and service elements supported, the valid range of values
for mandatory and optional attributes, and the status code behavior.
In this section, supported means that tag is sent with value if entered by user or from worklist.
This is the description of the DICOM tags to be sent for Modality Performed Procedure Step
SOP class.
The following tables describe the Modality Performed Procedure Step Sop Class N-CREATE,
N-SET and Final State Attributes.
Table 10.2–1: SOP Common Module
65
Table 10.2–2: Performed Procedure Step Relationship (continued)
66
Table 10.2–3: Performed Procedure Step Information (continued)
67
10.2.2 Operations
The equipment sends N-CREATE when the exam is being started by pressing ”Start Exam”.
The equipment sends N-SET after the exam is ended. The N-SET will include all acquired
images and structured reports’ UIDs and the status of COMPLETED or DISCONTINUED.
68
11 Storage Commitment Push Model SOP Class Definition
11.1 Introduction
This section of the DICOM Conformance Statement specifies the Storage Commitment Push
Model SOP Class, the optional attributes and service elements supported, the valid range of
values for mandatory and optional attributes, and the status code behavior.
11.2.2 Operations
The equipment sends the N-ACTION primitive (Storage Commitment Request) after successful
exam save to a DICOM Storage SCP.
The equipment may request Storage Commitment for the following SOP Class UIDs:
69
Table 11.2–3: SOP Class Table
Name UID
Ultrasound Multi-Frame Image Storage 1.2.840.10008.5.1.4.1.1.3.1
Ultrasound Image Storage 1.2.840.10008.5.1.4.1.1.6.1
Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7
Comprehensive SR 1.2.840.10008.5.1.4.1.1.88.33
Enhanced US Volume Storage 1.2.840.10008.5.1.4.1.1.6.2
The association for the N-ACTION is disconnected after processing the response. Thus, the
N-EVENT-REPORT must be sent on a separate association.
The Referenced Study Component Sequence Attribute is not supported.
The Transaction UID is valid until the request is confirmed, manually retried or manually
deleted.
The optional Storage Media File-Set ID and UID Attributes in the N-ACTION are not sup-
ported.
On receipt of an unsuccessful N-ACTION Response Status Code from the SCP, the request will
remain in the queue for the user to manually retry the request.
70
11.2.3 Notifications
The equipment will only listen for an N-EVENT-REPORT from the SCP in a new association
on the listen port for Verification and Storage Commitment.
If no answer is received, the request will remain in the send queue for manual retry or manual
deletion.
If a successful answer is received, the request will be removed from the send queue without
messages.
If a non-successful answer is received, the request will be left in the send queue and will be
marked as failed.
71
In case of a received N-EVENT-REPORT-RQ a N-EVENT-REPORT-RSP message will be sent
to the SCP. The sent status values are described in the following tables.
72
12 Print Management SOP Class Definition
12.1 Introduction
This section of the DICOM Conformance Statement specifies the supported Print Management
SOP and Meta SOP Classes, the optional attributes and service elements supported, the valid
range of values for mandatory and optional attributes, and the status code behavior.
The Basic Print Management Meta SOP Classes correspond with the minimum functionality
that an implementation of the Print Management Service Class shall support. The equipment
supports the Basic Grayscale Print Management Meta SOP Class and the Basic Color Print
Management Meta SOP Class. These are defined in Table 12.2–1 and 12.2–2.
The Basic Grayscale Print Management Meta SOP Class is defined by the following set of
supported SOP Classes.
The Basic Color Print Management Meta SOP Class is defined by the following set of supported
SOP Classes.
Table 12.2–2: Basic Color Print Management Meta SOP Class
73
12.3 Print Management SOP Class Definitions
The Basic Color Print Management Meta SOP Class is defined by the following set of supported
SOP Classes
Table 12.3–1: DIMSE Service Group
12.3.1.1.1 N-CREATE
The N-CREATE DIMSE Service is used by equipment to request that the SCP create a Film
Session SOP Instance see Table 12.4–1.
12.3.1.1.2 N-SET
12.3.1.1.3 N-DELETE
12.3.1.1.4 N-ACTION
The Basic Film Box IOD is an abstraction of the presentation of one film of the film session.
The DIMSE services that are applicable to the IOD are shown in the following Table.
74
12.3.2.1 DIMSE Service Group
12.3.2.1.1 N-CREATE
The N-CREATE DIMSE Service is used by equipment to request that the SCP create a Film
Box SOP Instance. Table 12.4–2 defines the Basic Film Box Presentation Module attributes
used in this request.
12.3.2.1.2 N-ACTION
The N-ACTION DIMSE Service is used by the equipment to request the SCP (printer) to print
the number of copies configured by the user to a film of the film session.
12.3.2.1.3 N-SET
12.3.2.1.4 N-DELETE
The N-DELETE DIMSE Service is used by the equipment to request the SCP (printer) to delete
the complete Film Box. The root Film Box Instance UID is sent to the SCP to accomplish
this.
The Basic Grayscale Image Box IOD is an abstraction of the presentation of an image and
image related data in the image area of a film. The DIMSE services that are applicable to the
IOD are shown in Table 12.3–3.
Table 12.3–3: DIMSE Service Group
The N-SET DIMSE Service is used by the equipment to update the Basic Grayscale Image Box
SOP Instance. Table 12.4–3 defines the Basic Image Box Presentation Module attributes used.
The Basic Color Image Box IOD is an abstraction of the presentation of an image and image
related data in the image area of a film. The DIMSE services that are applicable to the IOD
are shown in Table 12.3–4.
75
Table 12.3–4: DIMSE Service Group
The N-SET DIMSE Service is used by the equipment to update the Basic Color Image Box
SOP Instance. Table 12.4–3 defines the Basic Image Box Presentation Module attributes used.
The Printer IOD is an abstraction of the hard copy printer and is the basic Information Entity
to monitor the status of the printer. The DIMSE services that are applicable to the IOD are
shown in Table 12.3–5.
12.3.4.1.1 N-EVENT-REPORT
The equipment ignores the content of any N-EVENT-REPORT initiated by the SCP (Printer).
12.3.4.1.2 N-GET
Used by the equipment to request the SCP to get a Printer SOP Instance. Table 12.4–4 defines
the Printer Module attributes.
Within an entity of a DICOM Print Management, attributes are grouped into a related set of
attributes. A set of related attributes is termed a module. A module facilitates the understand-
ing of the semantics concerning the attributes and how the attributes are related with each
other. A module grouping does not infer any encoding of information into datasets.
Table 12.4–1, Table 12.4–2, Table 12.4–3 and Table 12.4–4 identify the defined modules within
the entities which comprise the DICOM Print Management Service IODs. Modules are identified
by Module Name. See DICOM for a complete definition of the entities, modules and attributes.
76
12.4.1.1 Film Session IOD Module
Please refer to DICOM Standard Part 3 (Information Object Definitions) for a description of
each of the entities and modules that comprise the Print Management. The following modules
are included to convey Enumerated Values, Defined Terms, and Optional Attributes supported.
77
12.5.1.1 General Modules
This section defines the attributes that are required for proper functioning and identification of
the associated SOP Instances. They do not specify any semantics about the Real-World Object
represented by the IOD.
For all user configurable tags with no default, no value will be sent if the tag is not configured.
This section defines the attributes that are common for all films of a film session. The attributes
described in table 12.5–2 apply when the N-CREATE DIMSE service is used.
78
12.5.1.2.2 Basic Film Session Relationship Module
The attributes described in Table 12.5–4 apply when the N-CREATE DIMSE service is used.
The system can be configured to not send the Magnification Type (2010,0060) (≥ 10.x.x).
79
12.5.1.2.4 Basic Film Box Relationship Module
This section defines the attributes that describe the common parameters, which apply for all
images on a given sheet of film.
The attributes described in Table 12.5–6 apply when the DIMSE Service N-SET is used.
80
Table 12.5–6: Image Box Pixel Presentation Module Attributes (continued)
This section defines the attributes that are used to monitor the status of the printer. The
attributes described in Table 12.5–7 apply when the DIMSE Service N-GET is used. Only
Failures will be displayed to the customer in the send queue. The reason for a possible failure
will not be displayed.
81
13 Study Root Query/Retrieve Information Model Definition
13.1 Introduction
This section specifies the use of the DICOM Study Root Query/Retrieve Model used to organize
data and against which a Query/Retrieve will be performed. The contents of this section are:
This section defines the implementation of the Study Root Query/Retrieve Information Model.
Please refer to DICOM Standard Part 3 (Information Object Definitions) for a description of
each of the entities contained within the Study Root Information Model.
DICOM Equipment
STUDY Patient
SERIES Exam
IMAGE Image
Please refer to DICOM Standard PS 3.4 (Service Class Specifications) for a description of each
of the levels contained within the Study Root Query/Retrieve Information Model. The following
Level descriptions are included to specify what data elements are supported and what type of
matching can be applied. It should be noted that they are the same ones as defined in the
DICOM Standard PS 3.4 (Service Class Specifications).
This section defines the keys at the Study Level of the Study Root Query/Retrieve Information
Model that are supported by this implementation. See Table 2.3–14.
82
The following conventions are used to defined they of keys used in Query/Retrieve Information
Models. Please refer to DICOM Standard part 4 for details on what Unique, Optional and
Required attribute means.
Symbol Description
U Unique Key Attribute
O Optional Key Attribute
R Unique Key Attribute
Table 13.4–2: Q/R Study Level and Location for Retrieve Attributes
This section defines the keys at the Series Level of the Study Root Query/Retrieve Information
Model that are supported by this implementation.
The Modality is always set to the value US.
Table 13.4–4: Series Level Attributes - Study Root Q/R Information Model
The following conventions are used to defined they of keys used in Query/Retrieve Information
Models. Please refer to DICOM Standard part 4 for details on what Unique, Optional and
83
Required attribute means.
Table 13.4–5: Q/R Study Level and Location for Retrieve Attributes
84
14 Audit Trail Message Format Profile
This section described the list of Audit Messages implemented by this product to conform to
the DICOM Audit Profile.
Audit Message Usage Reference
Application Activity Used 14.2.1
Audit Lof Used Not Used
Begin Transferring DICOM Instances Used 14.2.2
Data Export Used 14.2.3
Data Import Used 14.2.4
DICOM Instances Accessed Used 14.2.5
DICOM Instances Transferred Used 14.2.6
DICOM Study Deleted Used 14.2.7
Network Entry Not Used
Query Used 14.2.8
Security Alert Not Used
User Authentication Used 14.2.9
The following subsections define message details and specializations used by this product as
part of the DICOM Audit Trail Profile.
85
Table 14.2–1: Application Activity Message (continued)
This message describes the event of a system beginning to transfer a set of DICOM instances
from one node to another node within control of the system’s security domain. This message
only includes information about a single patient.
86
Table 14.2–2: Audit Message for Begin Transferring DICOM Instances (continued)
This message describes the event of exporting data from the system, meaning that the data
is leaving control of the system’s security domain. Example of exporting includes printing to
paper, conversion to another format of storage in an EHR, writing to removeable media or
sending via e-mail. A single patient is described in one event message.
87
Table 14.2–3: Audit Message for Data Export (continued)
This message describes the event of importing data into an organization, implying that the data
now entering the system was not under the control of the security domain of this organization.
An example of importing is creating new local instances from data on removable media. A
single patient is described in one event message. A single user (either local or remote) shall
be identified as the requestor, i.e., UserIsRequestor with a value of TRUE. This accommodates
both push and pull transfer models for media.
88
Table 14.2–4: Audit Message for Data Import (continued)
This message describes the event of DICOM SOP Instances being viewed, utilized, updated, or
deleted. This message includes information about a single patient and ¡Select¿can be used to
summarize all activity for several studies for that patient ¡or¿ summarize all activity for a single
Study. This message records ¡Select¿the studies ¡or¿ the Study to which the instances belong,
not the individual instances. If all instances within a study are deleted, then the EV(110105,
DCM, ”DICOM Study Deleted”) event is used, see Section 27.2.8.
89
Table 14.2–5: Audit Message for DICOM Instances Accessed (continued)
This message describes the event of the completion of transferring DICOM SOP Instances
between two Application Entities. This message only includes information about a single pa-
tient.
Table 14.2–6: Audit Message for DICOM Instance Transferred
90
Table 14.2–6: Audit Message for DICOM Instance Transferred (continued)
91
Table 14.2–6: Audit Message for DICOM Instance Transferred (continued)
This message describes the event of deletion of ¡Select¿ one or more studies and all associated
SOP Instances ¡or¿ a single Study and its associated SOP Instances in a single action. This
message only includes information about a single patient
92
Table 14.2–7: Audit Message for DICOM Study Deleted (continued)
14.2.8 Query
This message describes the event of a Query being issued or received. The message does not
record the response to the query, but merely records the fact that a query was issued:
1. Modality Worklist
2. UPS Pull
3. UPS Watch
93
Table 14.2–8: Audit Message for Query (continued)
94
Table 14.2–8: Audit Message for Query (continued)
This message describes the event that a user has attempted to log on or log off. This report is
made regardless of whether the attempt was successful or not. Note The user usually has UserIs-
Requestor TRUE, but in the case of a logout timer, the Node can be the UserIsRequestor.
95
Table 14.2–9: Audit Message for User Authentication (continued)
96
15 Known Limitations
We are aware of the following limitations in our DICOM implementation. Each of these limi-
tations may be overcome in future versions. Please see the detailed describtion below:
• The Voluson E6/E8/E10 does not offer Implicit VR Little Endian for JPEG Lossless
compressed images. Please refer to Table 12.5–7.
• The mandatory functional groups ”Frame VOI LUT” and ”Plane Orientation (Volume)
are currently not implemented in the Multi-frame Functional Groups Section 6.5.6.3.
• The ”Plane Position Functional Group” is currently located in the ”Shared Functional
Groups Sequence” and should be moved to the ”Per-frame Functional Groups Sequence”.
See Section 6.5.6.3.
• Currently the ”Acquisition Context Sequence” will not be transferred. See Section 6.5.6.5.
• The ”VOI LUT MACRO ATTRIBUTES” is missing in the Enhanced Palette Color
Lookup Table. See Section 6.5.6.6.
• ”Lossy Image Compression”, ”Lossy Image Compression Ratio” and ”Lossy Image Com-
pression Method” are not used if JPEG will be sent. See Section 6.5.6.7.
• ”Presentation LUT Shape” will not be transferred in the current version. See Section
6.5.6.7.
• The BSN support for the dutch requirement is currently handled via the Tags (0010,0020),
(0010,0021) and (0010,1000). In future versions also the Tag (0010, 1002) has to be
supported.
• Add ”Accession Number”, ”Study Instance UID”, ”Referenced Study Sequence” and
”Scheduled Protocol Code Sequence” to the ”General Series Module Attributes” Table
4.5–3 if copied from MWL.
• ”Current Requested Procedure Evidence Sequence” should be send. See Section 8.5.2.
• If ”Scheduled Protocol Code Sequence” will not be sent from the Worklist the sequence
should be empty for MPPS and should not be sent for Images. If the sequence will be
received from the Worklist but without the ”Code Meaning” the tag will be set equal to
the ”Code Value” 9.5–2.
• To avoid compatibility issues the Finding Site listed in the SonoVCAD-Labor Section will
be sent although this tag do not convey a anatomical location.
97
A Standard Extended and Private Context Groups - EC330
98
Table A.0–10: Context ID 4 Anatomic Region (continued)
99
Table A.0–10: Context ID 4 Anatomic Region (continued)
100
Table A.0–12: Context ID 221 Measurement Range Concepts
101
Table A.0–16: Context ID 227 Sample Statistical Descriptors
102
Table A.0–20: Context ID 271 Observation Subject Class (continued)
103
Table A.0–24: Context ID 6140 Calculation Methods
104
Table A.0–27: Context ID 7454 Species
105
Table A.0–30: Context ID 12003 OB-GYN DATES (continued)
106
Table A.0–32: Context ID 12005 Fetal Biometry Measurements (continued)
107
Table A.0–32: Context ID 12005 Fetal Biometry Measurements (continued)
108
Table A.0–36: Context ID 12009 Early Gestation Biometry Measurements
109
Table A.0–38: Context ID 12013 Gestational Age Equations and Tables (continued)
110
Table A.0–38: Context ID 12013 Gestational Age Equations and Tables (continued)
111
Table A.0–38: Context ID 12013 Gestational Age Equations and Tables (continued)
112
Table A.0–38: Context ID 12013 Gestational Age Equations and Tables (continued)
Table A.0–39: Context ID 12014 OB Fetal Body Weight Equations and Tables
113
Table A.0–40: Context ID 12015 Fetal Growth Equations and Tables
114
Table A.0–40: Context ID 12015 Fetal Growth Equations and Tables (continued)
115
Table A.0–40: Context ID 12015 Fetal Growth Equations and Tables (continued)
116
Table A.0–40: Context ID 12015 Fetal Growth Equations and Tables (continued)
117
Table A.0–40: Context ID 12015 Fetal Growth Equations and Tables (continued)
118
Table A.0–44: Context ID 12101 Vascular Summary
119
Table A.0–48: Context ID 12107 Upper Extremity Arteries (continued)
120
Table A.0–51: Context ID 12110 Lower Extremity Veins
121
Table A.0–55: Context ID 12115 Renal Vessels
122
Table A.0–58: Context ID 12121 Vascular Indices and Ratios (continued)
123
Table A.0–61: Context ID 12140 Pelvic Vasculature Anatomical Location
124
Table A.0–64: Context ID 12201 Left Ventricle Linear
125
Table A.0–67: Context ID 12204 Echocardiography Right Ventricle
126
Table A.0–70: Context ID 12207 Echocardiography Mitral Valve
127
Table A.0–72: Context ID 12209 Echocardiography Pulmonic Valve (continued)
128
Table A.0–75: Context ID 12212 Echocardiography Aorta (continued)
129
Table A.0–78: Context ID 12216 Echocardiography Hepatic Veins (continued)
130
Table A.0–82: Context ID 12222 Orifice Flow Properties (continued)
131
Table A.0–85: Context ID 12226 Echocardiography Image View
132
Table A.0–88: Context ID 12229 Echocardiography Area Methods
133
Table A.0–92: Context ID 12235 Mitral Valve Anatomic Sites
134
Table A.0–96: Context ID 12241 Tricuspid Valve Finding Sites
135
Table A.0–101: Context ID 99102 OB-GYN Amniotic Sac OLD
136
Table A.0–104: Context ID 99105 Fetal Echo Measurement
137
Table A.0–104: Context ID 99105 Fetal Echo Measurement (continued)
138
Table A.0–104: Context ID 99105 Fetal Echo Measurement (continued)
139
Table A.0–104: Context ID 99105 Fetal Echo Measurement (continued)
140
Table A.0–106: Context ID 99107 Fetal Echo Finding Site (continued)
141
Table A.0–108: Context ID 99109 Pelvic Floor Report (continued)
142
Table A.0–112: Context ID 99113 Mass and Cyst Measurements
143
Table A.0–114: Context ID 99115 Fetal Anatomy Item (continued)
144
Table A.0–114: Context ID 99115 Fetal Anatomy Item (continued)
145
Table A.0–114: Context ID 99115 Fetal Anatomy Item (continued)
146
Table A.0–115: Context ID 99116 Fetal Anatomy Normality Codes (continued)
147
Table A.0–116: Context ID 99117 Fetal Anatomy Item Details
148
Table A.0–116: Context ID 99117 Fetal Anatomy Item Details (continued)
149
Table A.0–116: Context ID 99117 Fetal Anatomy Item Details (continued)
150
Table A.0–117: Context ID 99118 IOTA SR Item (continued)
151
Table A.0–120: Context ID 99121 Z-Score Equations
152
Table A.0–122: Context ID 99123 Gyn Findings Item (continued)
153
Table A.0–123: Context ID 99124 Gyn Findings Normality Codes (continued)
154
Table A.0–123: Context ID 99124 Gyn Findings Normality Codes (continued)
155
Table A.0–123: Context ID 99124 Gyn Findings Normality Codes (continued)
156
Table A.0–124: Context ID 99125 Gyn Findings Item Details (continued)
157
B Standard Extended and Private Templates - EC330
158
Table B.0–126: TID 310 Measurement (continued)
159
Table B.0–130: TID 320 Image or Spatial Coordinates
160
Table B.0–133: TID 1001 OBSERVATION CONTEXT
161
Table B.0–136: TID 1004 DEVICE OBSERVER IDENTIFYING ATTRIBUTES
162
Table B.0–137: TID 1005 PROCEDURE CONTEXT (continued)
163
Table B.0–139: TID 1007 SUBJECT CONTEXT, PATIENT (continued)
164
Table B.0–140: TID 1008 SUBJECT CONTEXT, FETUS (continued)
165
Table B.0–141: TID 1009 SUBJECT CONTEXT, SPECIMEN (continued)
166
Table B.0–142: TID 5000 OB-GYN Ultrasound Procedure Report (continued)
167
Table B.0–142: TID 5000 OB-GYN Ultrasound Procedure Report (continued)
168
Table B.0–142: TID 5000 OB-GYN Ultrasound Procedure Report (continued)
169
Table B.0–145: TID 5003 OB-GYN PROCEDURE FETUS SUMMARY
170
Table B.0–147: TID 5005 FETAL BIOMETRY SECTION (continued)
171
Table B.0–150: TID 5008 FETAL BIOMETRY GROUP (continued)
172
Table B.0–151: TID 5009 FETAL BIOPHYSICAL PROFILE SECTION (continued)
173
Table B.0–153: TID 5011 EARLY GESTATION SECTION (continued)
174
Table B.0–155: TID 5013 FOLLICLES SECTION
175
Table B.0–157: TID 5015 PELVIS AND UTERUS SECTION (continued)
176
Table B.0–158: TID 5016 LWH VOLUME GROUP (continued)
177
Table B.0–161: TID 5100 VASCULAR ULTRASOUND REPORT
178
Table B.0–161: TID 5100 VASCULAR ULTRASOUND REPORT (continued)
179
Table B.0–161: TID 5100 VASCULAR ULTRASOUND REPORT (continued)
180
Table B.0–161: TID 5100 VASCULAR ULTRASOUND REPORT (continued)
181
Table B.0–161: TID 5100 VASCULAR ULTRASOUND REPORT (continued)
182
Table B.0–161: TID 5100 VASCULAR ULTRASOUND REPORT (continued)
183
Table B.0–164: TID 5104 VASCULAR ULTRASOUND MEASUREMENT GROUP (continued)
184
Table B.0–165: TID 5200 ECHOCARDIOGRAPHY ULTRASOUND REPORT (continued)
185
Table B.0–165: TID 5200 ECHOCARDIOGRAPHY ULTRASOUND REPORT (continued)
186
Table B.0–165: TID 5200 ECHOCARDIOGRAPHY ULTRASOUND REPORT (continued)
187
Table B.0–167: TID 5202 ECHO SECTION (continued)
188
Table B.0–169: TID 99000 Fetus Doppler Measurements
189
Table B.0–169: TID 99000 Fetus Doppler Measurements (continued)
190
Table B.0–169: TID 99000 Fetus Doppler Measurements (continued)
191
Table B.0–169: TID 99000 Fetus Doppler Measurements (continued)
192
Table B.0–169: TID 99000 Fetus Doppler Measurements (continued)
193
Table B.0–170: TID 99001 Maternal Doppler Measurements (continued)
194
Table B.0–171: TID 99002 FIBROID SECTION
195
Table B.0–173: TID 99004 Fetal Anatomy (continued)
196
Table B.0–174: TID 99005 AMNIOTIC SAC SECTION OLD
197
Table B.0–176: TID 99007 SonoVCADLabor MEASUREMENT GROUP (continued)
198
Table B.0–180: TID 99011 Fetal Echo GROUP
199
Table B.0–183: TID 99014 Cardiovascular Profile Score (continued)
200
Table B.0–186: TID 99017 FETAL Placenta GROUP
201
Table B.0–188: TID 99019 MVP SECTION
202
Table B.0–191: TID 99022 Generic Cyst SECTION (continued)
203
Table B.0–194: TID 99025 Ovarian Mass SECTION (continued)
204
Table B.0–196: TID 99027 CYST MEASUREMENT GROUP (continued)
205
Table B.0–199: TID 99030 IOTA Simple Rules Findings
206
Table B.0–202: TID 99033 User Defined Measurements SECTION (continued)
207
Table B.0–205: TID 99101 Voluson Ultrasound Graft Section (continued)
208