NNTDicom

DICOM Conformance Statement

rev. 05

June 23th, 2020

Cod. 97070041
Issued by:

CEFLA s.c
Via Bicocca 14/c
40026 Imola (BO) Italy
Internet: [Link]
 Dicom Conformance Statement - Page 3 of 33

1. CONFORMANCE STATEMENT OVERVIEW

NNTDicom software permit the integration between NNT/iRYS and health care facility software using Dicom
SOP Classes and Services.

o It uses DICOM services to send/receive image to/from remote workstations.

o It allows a user to query for modality worklist information from a remote information system
computer
o It is capable of printing images to DICOM printers
 Dicom Conformance Statement - Page 4 of 33

TABLE OF CONTENTS
1. CONFORMANCE STATEMENT OVERVIEW ........................................................................................... 3
3. INTRODUCTION ................................................................................................................................... 6
3.1 REVISION NOTES ........................................................................................................................... 6
3.2 AUDIENCE...................................................................................................................................... 6
3.3 SCOPE AND FIELD OF APPLICATION .............................................................................................. 6
3.4 TERMS AND DEFINITIONS ............................................................................................................. 6
3.5 BASICS OF DICOM COMMUNICATION .......................................................................................... 8
3.6 ABBREVIATIONS ............................................................................................................................ 9
3.7 REFERENCES .................................................................................................................................. 9
3.8 IMPORTANT CONSIDERATION FOR THE READER .......................................................................... 9
4 IMPLEMENTATION MODEL ................................................................................................................ 10
4.1 Application Data Flow Diagram .................................................................................................. 10
4.2 Functional Definition of AE's ....................................................................................................... 10
4.2.1 gsqSpooler............................................................................................................................ 10
4.2.2 gsqScp .................................................................................................................................. 11
4.2.3 gsqMWLQuery ..................................................................................................................... 11
4.2.4 gsqQueryRetrieve ................................................................................................................ 11
5 AE SPECIFICATIONS ............................................................................................................................ 12
5.1 NNTDicom Services AE Specifications ......................................................................................... 12
5.1.1 Association Establishment Policies ...................................................................................... 12
5.1.2 Association Initiation Policy ................................................................................................. 12
5.1.3 Association Acceptance Policy ............................................................................................. 21
5.2 NNTDicom Media Server AE ....................................................................................................... 23
5.2.1 Application Data Flow Diagram............................................................................................ 23
5.2.2 File Meta Information .......................................................................................................... 23
5.2.3 AE Specifications .................................................................................................................. 23
5.2.4 Character sets ...................................................................................................................... 24
6. Communication Profile ..................................................................................................................... 25
6.1 Supported Communication Stacks .............................................................................................. 25
6.2 OSI Stack...................................................................................................................................... 25
6.3 TCP/IP Stack ................................................................................................................................ 25
6.4 Physical Media Support .............................................................................................................. 25
6.5 Point to Point Stack ..................................................................................................................... 25
 Dicom Conformance Statement - Page 5 of 33

7. Extensions/Specializations/Privatizations......................................................................................... 26
7.1 Standard Extended/Specialized/Private SOPs ............................................................................ 26
7.2 Private Transfer Syntaxes............................................................................................................ 26
8. IOD Specific Implementation details................................................................................................. 27
8.2 IOD Contents ............................................................................................................................... 27
8.2 Data Dictionary ........................................................................................................................... 27
8.2.1 CT Image IOD Modules......................................................................................................... 27
8.2.2 SC Image IOD Modules ......................................................................................................... 27
8.2.3 DX Image IOD Modules ........................................................................................................ 27
8.2.4 IO Image IOD Modules ......................................................................................................... 28
8.2.5 IOD Tags ............................................................................................................................... 28
8.2.6 MPPS Radiation Dose Tags................................................................................................... 32
9. Configuration .................................................................................................................................... 33
9.1 Configuration AE Title/Presentation Address Mapping .............................................................. 33
9.2 Configurable Parameters ............................................................................................................ 33
10. Support of Characters Sets ............................................................................................................. 33
11. Security profiles .............................................................................................................................. 33
 Dicom Conformance Statement - Page 6 of 33

3. INTRODUCTION

3.1 REVISION NOTES

Rev. 05: Note about tag 0010,0010 Patient’s Name (section [Link].3)

3.2 AUDIENCE
This document is written for the people that need to understand how NNT/iRYS softwares will integrate into
their health care 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.

3.3 SCOPE AND FIELD OF APPLICATION

It is the intent of this document to provide an unambiguous specification for NNT/iRYS softwares
implementation. This specification includes a DICOM Conformance Statement and is necessary to ensure
proper processing and interpretation of NNT/iRYS medical data exchanged using DICOM v3.0. The NNT/iRYS
Conformance Statements are available to the public.
Included in this DICOM Conformance Statement are the Module Definitions, which define all data elements,
used by this NNT/iRYS implementation. If the user encounters unspecified private data elements while parsing
a NNT/iRYS 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 NNT/iRYS softwares.

3.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).
 Dicom Conformance Statement - Page 7 of 33

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.

Joint Photographic Experts Group (JPEG) – a set of standardized image compression techniques, available for
use by DICOM applications.

Media Application Profile – the specification of DICOM information objects and encoding exchanged on
removable media (e.g., CDs)

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.

Security Profile – a set of mechanisms, such as encryption, user authentication, or digital signatures, used by
an Application Entity to ensure confidentiality, integrity, and/or availability of exchanged DICOM data

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).

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
 Dicom Conformance Statement - Page 8 of 33

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.

3.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 CD-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.
 Dicom Conformance Statement - Page 9 of 33

3.6 ABBREVIATIONS
AE Application Entity
CD-R Compact Disk Recordable
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
ECT Enhanced Computed Tomography
FSC File-Set Creator
FSU File-Set Updater
FSR File-Set Reader
HIS Hospital Information System
IOD Information Object Definition
ISO International Organization for Standards
IO Intra-oral X-ray
JPEG Joint Photographic Experts Group
OSI Open Systems Interconnection
PACS Picture Archiving and Communication System
PDU Protocol Data Unit
RIS Radiology Information System.
SC Secondary Capture
SCP Service Class Provider
SCU Service Class User
SOP Service-Object Pair
TCP/IP Transmission Control Protocol/Internet Protocol
VL Visible Light
VR Value Representation

3.7 REFERENCES
NEMA PS3 Digital Imaging and Communications in Medicine (DICOM) Standard, available free at
[Link]

Software Manuals, available on the product CD-ROM.

3.8 IMPORTANT CONSIDERATION FOR THE READER

The DICOM conformance statement by itself is not sufficient to guarantee a successful connectivity between
NNT/iRYS and other applications.
 Dicom Conformance Statement - Page 10 of 33

4 IMPLEMENTATION MODEL
The NNTDicom services are implemented as separate applications that share a common Application Entity
Title.

4.1 Application Data Flow Diagram

The implementation model for the software application is the following:

Figura 1. Application Data Flow Diagram

In the central column, the NNTDicom module involved in the operation is explicated.

4.2 Functional Definition of AE's

4.2.1 gsqSpooler

It’s started at the system startup and is a connection initiator for Store Requests, print activities, Commitment
N-EVENT-REPORT requests and MPPS reporting messages.
 Dicom Conformance Statement - Page 11 of 33

4.2.2 gsqScp

It’s started at the system startup and accepts connections for Store requests and Storage Commitment N-
EVENT-REPORT responses.

4.2.3 gsqMWLQuery

It’s a user application which initiates connections to query a Modality Worklist and display the results of the
query.

4.2.4 gsqQueryRetrieve

It's a user application which initiates connections to query a remote node, display the results of the query and
send a move request for retrieval.
 Dicom Conformance Statement - Page 12 of 33

5 AE SPECIFICATIONS
5.1 NNTDicom Services AE Specifications
5.1.1 Association Establishment Polices

[Link] General
The configuration of the NNTDicom Services is made through the gsqConfig application which defines the port
number, Application Entity Title and maximum number of simultaneous associations. The accepted and
proposed Present Contexts can be also modified.

[Link] Number of associations

The NNTDicom connection service supports multiple simultaneous associations as an SCP. The number is
configurable via the gsqConfig application.
When receiving images or processing verification the SCP connection service will start a new thread for each
association being handled.

[Link] Synchronous Nature

The NNTDicom services don not support asynchronous operations and will not perform asynchronous window
negotiation.

[Link] Implementation Identifying Information

The implementation Class UID is: [Link].1.3680043.2.120.20000624
The version name is: G2/W32/ 2.8

5.1.2 Association Initiation Policy

NNTDicom initiates associations for the following activities:

 New IODs are created and sent to another system.

 The user wants to send images from the local storage to a remote system.
 The user wants to verify the DICOM communication with another system.
 The user wants to query the contents of a remote system.
 The user wants to retrieve the contents of a remote system.
 The user wants to query the Modality Worklist.
 The user wants to print to a DICOM printer.
 The system notifies the creation of one or more images (MPPS)
 The system notifies X-Ray data of a new acquisition (SR Document).

[Link] Verify Communication with a Remote System

The user wants to test the Dicom communication with a remote DICOM node; gsqMWLQuery or
gsqQueryRetrieve initiate an association.
 Dicom Conformance Statement - Page 13 of 33

[Link].1 Proposed Presentation Context

Presentation Context Table
Abstract Syntax Transfer Syntax Role Extended
Name UID Name UID negotiation
Verification 1.2.840.10008.1.1 Implicit VR 1.2.840.10008.1.2 SCU none
Little Endian

[Link].2 SOP Specific Conformance Statement for SOP Class Verification

NNT/iRYS provides standard conformance.

[Link] Send DICOM objects to a Remote System

There are two possible situations for which a CSTORE operation can be initiated:

1. Send user selected objects from the local storage through gsqSpooler.
2. New IODs are created, locally stored and forwarded to an Image Archive DICOM Server through
gsqSpooler.

[Link].1 Associated Real World Activity

The user executes a query to the local database and then sends a series/study to a remote system or new SOP
instances must be saved from within NNT/iRYS. gsqSpooler initiates the association with the destination
system.

[Link].2 Proposed Presentation Context

gsqSpooler proposes all the storage SOP classes and Transfer Syntaxes defined in the [Link] file.
At the moment the following are supported:

Abstract Syntax Role

UID Name
1.2.840.10008.[Link].1.2 CT Image Storage SCU
1.2.840.10008.[Link].1.1.1 Digital X-Ray Image Storage For Presentation SCU
1.2.840.10008.[Link].1.1.3 Digital Intra Oral X-Ray Image Storage For Presentation SCU
1.2.840.10008.[Link].1.1.7 Secondary Capture Image Storage SCU
1.2.840.10008.[Link].1.12.1 XA Image Storage SCU
1.2.840.10008.[Link].1.88.67 XRay Radiation dose SR SCU
1.2.840.10008.1.20.1 Storage Commitment Push Model SCU

Supported transfer syntaxes are:

1.2.840.10008.1.2 Implicit Little Endian
1.2.840.10008.1.2.1 Explicit Little Endian
1.2.840.10008.[Link] JPEG Lossless

[Link].3 SOP Specific Conformance Statement for SOP Class Storage

gsqSpooler provides standard conformance.

[Link].4 SOP Specific Conformance Statement for Storage Commitment PUSH model
gsqSpooler provides standard conformance as SCU.
 Dicom Conformance Statement - Page 14 of 33

[Link] Query a Remote System

[Link].1 Associated Real World Activity

A user wants to query a remote system through the use of the gsqQueryRetrieve application. He or she fills a
dialog box with the query values, eventually using wildcards instead of fully specified information to allow for
flexible queries.

[Link].2 Proposed Presentation Context

Presentation Context Table
Abstract Syntax Transfer Syntax Role Extended
Name UID Name UID negotiation
Study Root 1.2.840.10008.[Link].2.2.1 Implicit VR 1.2.840.10008.1.2 SCU none
Query/Retrieve – FIND Little Endian

[Link].3 SOP Specific Conformance Statement for SOP Class Query

gsqQueryRetrieve does not support Relational Queries. For a Study Root Query the following keys are
supported:

Supported keys for Study Root Query

Level Description Tag Type
Study Study Date (0008,0020) M = Matching value
Study Study time (0008,0030) R = Return value
Study Accession Number (0008,0050) M
Study Patient’s name (0010,0010) M
Study Patient ID (0010,0020) M
Study Study ID (0020,0010) M
Study Study Instance UID (0020,000D) R
Study Study description (0008,1030) M
Study Patient’s Birth Date (0010,0030) M
Study Patient’s Sex (0010,0040) M
Study Modalities in study (0008,0061) M
Study Body Part Examined (0018,0015) M
Study Number of Study related series (0020,1206) R
Study Number of Study related instances (0020,1208) R
Study Retrieve AE Title (0008,0054) R
Series Modalità (0008,0060) R
Series Series Number (0008,0011) R
Series Series Instance UID (0008,0010) R
Series Number of series related Instances (0020,1209) R

gsqQueryRetrieve expects the remote SCP to perform anyone of the following Matching methods:

Matching methods for Study/Patient Root Query

Single value matching
Universal matching
Wild Card Matching
Range Matching
 Dicom Conformance Statement - Page 15 of 33

[Link] Retrieve from a Remote System

[Link].1 Associated Real World Activity

After a view of a remote DICOM database has been obtained the user makes a selection of one or more
studies/series and then presses the [Get] button. This will initiate the transfer of the images from the remote
system to the local NNT/iRYS database via a C-MOVE request to the 'Retrieve AE Title' with destination the
gsqSCP Application Entity Title

[Link].2 Proposed Presentation Context

Presentation Context Table
Abstract Syntax Transfer Syntax Role Extended
Name UID Name UID negotiation
Study Root 1.2.840.10008.[Link].2.2.2 Implicit VR 1.2.840.10008.1.2 SCU none
Query/Retrieve – MOVE Little Endian

[Link].3 SOP Specific Conformance Statement for SOP Class Retrieve

NNT/iRYS provides standard conformance.
gsqQueryRetrieve for a Study Root Retrieve supports the following keys:

Supported keys for Study Root Retrieve

Level Description Tag Type
Study Study Instance UID (0020,000D) M
Series Series Instance UID (0008,0010) M

gsqQueryRetrieve does only exact matching for a retrieval request.

[Link] Query a Modality Worklist SCP

[Link].1 Associated Real World Activity

A user wants to query a Modality Worklist server through the use of the gsqMWLQuery application. He or she
fills a dialog box with the query values, eventually using wildcards instead of fully specified information to
allow for flexible queries.

[Link].2 Proposed Presentation Context

Presentation Context Table
Abstract Syntax Transfer Syntax Role Extended
Name UID Name UID negotiation
Modality Worklist 1.2.840.10008.[Link] Implicit VR 1.2.840.10008.1.2 SCU none
Information Model - FIND Little Endian

[Link].3 SOP Specific Conformance Statement for SOP Class Query

gsqMWLQuery does not support Relational Queries. For a Modality Worklist Query the following keys are
supported:

Supported keys for Modality Worklist Query

Description Tag Type
Accession Number (0008,0050) M = Matching value
Patient’s name (0010,0010) M
Patient ID (0010,0020) M
 Dicom Conformance Statement - Page 16 of 33

Scheduled Procedure Step Sequence (0040,0100)

>Scheduled Procedure Step Start Date (0020,0010) M
>Scheduled Procedure Step Start Time (0020,0010) M
>Scheduled Station AE Title (0040,0001) M
>Modality (0008,0060) M
>Scheduled Procedure Step ID (0040,0009) R = Return value
>Scheduled Procedure Step Description (0040,0007) R
>Scheduled Protocol Code Sequence (0040,0008) R
Requested Procedure Description (0032,1060) R
Requested Procedure Code Sequence (0032,1064) R
Requested Procedure ID (0040,1001) M
Study Instance UID (0020,000D) R
Referenced Study Sequence (0008,1110) R
Referring Physicians Name (0008,0090) R
Patients Address (0010,1040) R
Patients Telephone Numbers (0010,2154) R

These keys can be modified by creating a folder in the same directory of gsqMWLQuery and creating a
[Link] file with the following format:
<?xml version="1.0" encoding="UTF-8"?>
<dicomObject version="1.0">
<dataSet>
<seq tag="ScheduledProcedureStepSequence">
<item idx="0">
<vr tag="ScheduledStationAETitle"></vr>
<vr tag="ScheduledProcedureStepStartDate"></vr>
<vr tag="ScheduledProcedureStepStartTime"></vr>
<vr tag="Modality"></vr>
<vr tag="ScheduledProcedureStepID"></vr>
<vr tag="ScheduledProcedureStepDescription"/>
<vr tag="ScheduledProtocolCodeSequence"/>
</item>
</seq>
<vr tag="RequestedProcedureDescription"/>
<vr tag="RequestedProcedureCodeSequence"/>
<vr tag="RequestedProcedureID"/>
<vr tag="StudyInstanceUID"/>
<vr tag="ReferencedStudySequence"/>
<vr tag="AccessionNumber"/>
<vr tag="ReferringPhysiciansName"/>
<vr tag="PatientsName"/>
<vr tag="PatientID"/>
<vr tag="PatientsBirthDate"/>
<vr tag="PatientsSex"/>
<vr tag="PatientsAddress"/>
<vr tag="PatientsTelephoneNumbers"/>
</dataSet>
</dicomObject>

gsqMWLQuery expects the remote SCP to perform anyone of the following Matching methods:

Matching methods for Modality Worklist Query

Single value matching
Universal matching
Wild Card Matching
Range Matching
 Dicom Conformance Statement - Page 17 of 33

Note on (0010,0010) Patient’s Name tag:

NNT/iRYS rev. 11.5 (or later) supports full syntax of (0010,0010) Patient’s Name tag in the software Database.
Previous NNT/iRYS releases support only first two components of PN (Person Name) Dicom tag, so for the tag
0010,0010 only “family name” and “given name” will be inserted into the software database.

[Link] Print studies and Images to a DICOM-compliant printer

[Link].1 Associated Real World Activity

The user selects images and their viewing window to print them onto a DICOM-compliant printer. When the
user presses the [Print] button on the print dialog NNT/iRYS send a print order to gsqSpooler which in turn
tries to establish a connection to the DICOM compliant printer and sends pre-formatted images for printing.

[Link].2 Proposed Presentation Context

Presentation Context Table
Abstract Syntax Transfer Syntax Role Extended
negotiation
Name UID Name UID
Basic Grayscale Print Management Meta 1.2.840.10008.[Link] Implicit VR 1.2.840.10008.1.2 SCU None
Printer SOP Class 1.2.840.10008.[Link] Little Endian SCU None
Basic Color Print Management Meta 1.2.840.10008.[Link] SCU None
Basic Printer SOP Class UID 1.2.840.10008.[Link] SCU None
Basic Color Image Box SOP Class 1.2.840.10008.[Link].1 SCU None
Presentation LUT SOP Class 1.2.840.10008.[Link] SCU None

[Link].3 SOP Specific Conformance for Basic Grayscale Management SOP Classes
gsqSpooler supports the following mandatory SOP Classes which are defined under the Basic Grayscale Print
Management Meta SOP and Basic Color Print Management Meta SOP Classes.

SOP Classes as SCU

Sop Classes Name UID
Basic Film Session SOP Class 1.2.840.10008.[Link]
Basic Film Box SOP Class 1.2.840.10008.[Link]
Basic Grayscale Image Box SOP Class 1.2.840.10008.[Link]
Basic Color Image Box SOP Class 1.2.840.10008.[Link].1
Printer SOP Class 1.2.840.10008.[Link]

[Link].3.1 Basic Film Session SOP Class

gsqSpooler supports the following DIMSE Service Elements for Basic Film Session SOP Class:

 N-CREATE – Requests to create an instance of Basic Film Session.

The following are the attribute values supported by the Basic Film Session SOP Class

Description Tag Default value

Number of copies (2000,0010) 1

Print Priority (2000,0020) NULL

Medium Type (2000,0030) NULL

Film Destination (2000,0040) NULL

Film Session Label (2000,0050) NULL

Film Illumination (2000,015E) NULL

 Dicom Conformance Statement - Page 18 of 33

Reflective Ambient Light (2010,0160) NULL

[Link].3.2 Basic Film Box SOP Class

gsqSpooler supports the following DIMSE Service Elements for Basic Film Box SOP Class:
 N-CREATE – Requests to create an instance of Basic Film Box.
 N-ACTION – Requests to print a Film Box onto Printer
 N-DELETE – Requests to delete an instance of Basic Film Box.

The following are the attribute values supported by the Basic Film Box SOP Class:

Description Tag Default value

Image Display Format (2010,0010) STANDARD\1,1

Film Orientation (2010,0040)

Film Size ID (2010,0050)

Magnification Type (2010,0060)

Smoothing Type (2010,0080)

Border Density (2010,0100)

Empty Image Density (2010,0110)

Min Density (2010,0120)

Max Density (2010,0130)

Configuration Information (2010,0150)

[Link].3.3 Basic Grayscale Image Box SOP Class

gsqSpooler supports the following DIMSE Service Elements for Grayscale Image Box SOP Class:

 N-SET – Requests to set the Image Box attributes.

The following are the attribute values supported by the Basic Grayscale Image Box SOP Class

Description Tag Default value

Image Position (2020,0010) Image dependent

Polarity (2020,0020)

Preformatted Grayscale Image Sequence (2020,0110)

> Samples per Pixel (2028,0002) 1

> Photometric Interpretation (2028,0004) MONOCHROME2

> Rows (2028,0010) Image dependent

> Columns (2028,0011) Image dependent

> Pixel Aspect Ratio (2028,0034) 1\1

> Bits Allocated (2028,0100) 8/10/12

> Bits Stored (2028,0101) 8/16

> High Bit (2028,0102) 7

> Pixel Representation (2028,0103) 0

> Pixel Data (7FE0,0010)

[Link].3.4 Basic Color Image Box SOP Class

gsqSpooler supports the following DIMSE Service Elements for Color Image Box SOP Class:

 N-SET – Requests to set the Image Box attributes.

 Dicom Conformance Statement - Page 19 of 33

The following are the attribute values supported by the Basic Color Image Box SOP Class

Description Tag Default value

Image Position (2020,0010) Image dependent

Polarity (2020,0020)

Preformatted Color Image Sequence (2020,0111)

> Samples per Pixel (2028,0002) 3

> Photometric Interpretation (2028,0004) RGB

> Rows (2028,0010) Image dependent

> Columns (2028,0011) Image dependent

> Pixel Aspect Ratio (2028,0034) 1\1

> Bits Allocated (2028,0100) 8

> Bits Stored (2028,0101) 8

> High Bit (2028,0102) 7

> Pixel Representation (2028,0103) 0

> Pixel Data (7FE0,0010)

[Link].3.5 Printer SOP Class

gsqSpooler issues the request to retrieve the following attributes from DICOM-Compliant printers:

 C-GET – Retrieve printer information.

Description Tag Default value

Printer Status (2110,0010) Printer dependent

Printer Status Info (2110,0020) Printer dependent

Printer Name (2110,0030) Printer dependent

Manufacturer (0008,0070) Printer dependent

Manufacturer Model Name (0008,1090) Printer dependent

Device Serial Number (0018,1000) Printer dependent

Software Versions (0018,1020) Printer Dependent

Last Calibration Date (0018,1200) Printer Dependent

Last Calibration Time (0018,1201) Printer Dependent

[Link] Modality Performed Procedure Step (MPPS)

[Link].1 Associated Real World Activity

The system creates new IODs and sends a notification to the MPPS SCP with the SOP Instances created.

[Link].2 Proposed Presentation Context

gsqSpooler proposes the following presentation context:

Abstract Syntax Transfer Syntax Role

UID Name Name UID
1.2.840.10008.[Link].3 Modality Performed Procedure Step Implicit Little Endian 1.2.840.10008.1.2 SCU
 Dicom Conformance Statement - Page 20 of 33

[Link].3 SOP Specific Conformance Statement for SOP Class

The NNTDicom MPPS service sends MPPS N-CREATE and N-SET messages.
The following attributes may be included in the MPPS N-CREATE message:

Description Tag
Specific Characters Set 0008,0005

Modality 0008,0060

Procedure Code Sequence 0008,1032

Referenced Patient Sequence 0008,1120

Patient Name 0010,0010

Patient ID 0010,0020

Patient Birth Date 0010,0030

Patient Sex 0010,0040

Study ID 0020,0010

Performed Station AE Title 0040,0241

Performed Station Name 0040,0242

Performed Location 0040,0243

Performed Procedure Step Start Date 0040,0244

Performed Procedure Step Start Time 0040,0245

Performed Procedure Step End Date 0040,0250

Performed Procedure Step End Time 0040,0251

Performed Procedure Step Status 0040,0252

Performed Procedure Step ID 0040,0253

Performed Procedure Step Description 0040,0254

Performed Procedure Step Type Description 0040,0255

Performed Action Item Sequence 0040,0260

Scheduled Step Attributes Sequence 0040,0270

>Accession Number 0008,0050

>Referenced Study Sequence 0008,1110

>Study Instance UID 0020,000D

>Requested Procedure Description 0032,1060

>Scheduled Procedure Step Description 0040,0007

>Scheduled Action Item Code Sequence 0040,0008

>Scheduled Procedure Step ID 0040,0009

Performed Series Sequence 0040,0340

The following attributes may be included in the MPPS N-SET message:

Description Tag
Performed Procedure Step Status 0040,0252

Performed Series Sequence 0040,0340

>Retrieve AE Title 0008,0054

>Series Description 0008,103E

 Dicom Conformance Statement - Page 21 of 33

>Performing Physician Name 0008,1050

>Operator's Name 0008,1070

>Referenced Image Sequence 0040,0340

>>Referenced SOP Class UID 0008,1150

>>Referenced SOP Instance UID 0008,1155

5.1.3 Association Acceptance Policy

NNT/iRYS accepts remote associations requests for the following reasons

 verification of the DICOM protocol communication.

 Storage of images received from a remote system.
 Commitment notifications of images from a remote system.

Association request from an unknown AE Title will be rejected or can be accepted depending on the
configuration.

[Link] Verify Communication with a remote system

[Link].1 Associated Real World Activity

gsqSCP will respond to verification requests made by a remote system.

[Link].2 Accepted presentation contexts

Presentation Context Table
Abstract Syntax Transfer Syntax Role Extended
negotiation
Name UID Name UID
Verification 1.2.840.10008.1.1 Implicit VR 1.2.840.10008.1.2 SCP none
Little Endian

[Link].3 SOP specific Conformance Statement for SOP Class Verification

gsqSCP provides standard conformance.

[Link].4 Presentation Context Acceptance Criterion

There are no specific rules as long as the Presentation Context matches one of the above.

[Link] Receive Images from a Remote System

[Link].1 Associated Real World Activity

A remote system wants to send images to gsqSCP. Once received the images will be immediately available in
the local file system to the NNT/iRYS application.

[Link].2 Accepted Presentation Contexts

gsqSCP accepts all the storage SOP classes and Transfer Syntaxes defined in [Link].
Refer to [Link].2 for the list of supported classes.
 Dicom Conformance Statement - Page 22 of 33

[Link].3 SOP Specific Conformance Statement for SOP Class Storage

gsqSCP conforms to the full conformance of the storage SOP Class. All Type 1, 2 and 3 attributes will be
retained and included when the images are sent.
In case of Implicit transfer syntaxes private tags will be treated as ‘UN’ typecode.
When an images is received that is already present in the local file system, the previous instance will be
superseded by the new image.

[Link].4 Presentation Context Acceptance Criterion

There are no specific rules for acceptance and priorization of presentation contexts as long as they match
those listed in the table shown above. Generally the transfer syntax priority will be given depending on the
order they arrive in the presentation context, i.e. the first accepted transfer syntax found in the list of the
presentation context will be chosen.

[Link] Receive Storage Commitment Notifications

[Link].1 Associated Real World Activity

A remote system has stored the sent images and return the Storage Commitment Result Notification to
gsqSCP.

[Link].2 Accepted Presentation Contexts

Presentation Context Table
Abstract Syntax Transfer Syntax Role Extended
Name UID Name UID negotiation
Storage Commitment Push Model 1.2.840.10008.1.20.1 Implicit VR Little Endian 1.2.840.10008.1.2 SCU none

[Link].3 SOP Specific Conformance Statement for SOP Class Query

gsqScp provides standard conformance.

[Link].4 Presentation Context Acceptance Criterion

There are no specific rules for acceptance and priorization of presentation contexts as long as they match
those listed in the table shown above.
 Dicom Conformance Statement - Page 23 of 33

5.2 NNTDicom Media Server AE

NNT/iRYS provides standard conformance to the DICOM Media Storage Service and File Format (PS 3.10) and
the Media Storage Application Profiles (PS 3.11) as far as the reading and creation of uncompressed images on
supported File System is concerned.

5.2.1 Application Data Flow Diagram

Write
objects
NNT FSR
Media
AE Storage
FSC Medium

Read
objects

Figure 2: Media Storage Application Data Flow Diagram

NNT/iRYS Media AE displays the contents of Storage Medium and reads the images saving them to local
database.
NNT/iRYS Media AE writes data from the local database to the Storage Medium.

5.2.2 File Meta Information

The implementation Class UID is: [Link].x
The version name is: Software version id (in X_y format)

5.2.3 AE Specifications

[Link] Application Entity NNT/iRYS Service Specification

NNT/iRYS supports the following application profile:

Supported Application Profiles

Description Identifier
General purpose CD-R Image Interchange profile STD-GEN-CD

[Link] Real-World activities

NNT/iRYS supports the following Real World Activities within the profile mentioned above:

Real World Activities and Roles

Supported Application Profiles Real World Activity Role
STD-GEN-CD Read Image(s) from CD-R disk FSR
Write Image(s) on supported File System FSC
 Dicom Conformance Statement - Page 24 of 33

[Link].1 Real World Activity: Read images from CD-R disk or file system
NNT/iRYS will act as a FSR when reading from the directory of the medium.
By selecting a Dicom image on a supported File System the user can import the images to the local DataBase.
Only images created by NNT/iRYS Media AE can be imported.

[Link].2 Real World Activity: Write images to file system

The user can export single o sequence of images of an NNT/iRYS document on a supported file system. Dicom
data can be written to a CD-R or DVD-R using a commercial software.
NNT/iRYS is able to write images for the following SOP classes:

SOP Classes for writing DICOM Part 10 objects

1.2.840.10008.[Link].1.2 CT Storage
1.2.840.10008.[Link].1.7 SC Storage
1.2.840.10008.[Link].1.1.1 Digital X-Ray Image Storage For Presentation
1.2.840.10008.[Link].1.1.3 Intraoral Image Storage
1.2.840.10008.[Link].1.12.1 XA Image Storage

NNT/iRYS is able to write the DICOM Objects with the following transfer syntaxes:

Transfer syntaxes for writing DICOM Part 10 objects

Name UID
Explicit VR, Little Endian 1.2.840.10008.1.2.1

The following keys are written to the DICOMDIR file:

Keys exported to the DICOMDIR file

Record Type Key Description Tag Type
Patient Patient Name 0010,0010 2
Patient Patient ID 0010,0020 1
Patient Patient Date of Birth 0010,0030 3
Patient Patient Sex 0010,0040 3
Study Study Instance UID 0020,000D 1
Study Study ID 0020,0010 1
Study Study Date 0008,0020 1
Study Study Time 0008,0030 1
Study Accession Number 0008,0050 1
Study Study Description 0008,1030 3
Series Modality 0008,0060 1
Series Series Instance UID 0020,000E 1
Series Series Number 0020,0011 1
Image Image Type 0008,0008 1
Image Image Number 0020,0013 1

5.2.4 Character sets

NNT/iRYS Media AE supports the following extended character set (selectable by user):

- ISO-IR 100 - Latin alphabet No. 1, supplementary set

- ISO-IR 192 - Unicode UTF-8

NNT/iRYS Media AE does not change the character set of incoming objects before writing them, therefore the
character set depends on the system creating the DICOM objects.
 Dicom Conformance Statement - Page 25 of 33

6. Communication Profile
6.1 Supported Communication Stacks
The NNTDicom services provide DICOM 3.0 TCP/IP Network Communication Support as defined in Part 8 of
the DICOM standard.

6.2 OSI Stack

Not supported.

6.3 TCP/IP Stack

The NNTDicom Services use the TCP/IP stack from the Microsoft Windows operating system upon which it
executes.

6.4 Physical Media Support

The NNTDicom services do not depend upon the physical media over which the TCP/IP executes.

6.5 Point to Point Stack

Not supported.
 Dicom Conformance Statement - Page 26 of 33

7. Extensions/Specializations/Privatizations
7.1 Standard Extended/Specialized/Private SOPs
Not applicable.

7.2 Private Transfer Syntaxes

Not applicable.
 Dicom Conformance Statement - Page 27 of 33

8. IOD Specific Implementation details

8.2 IOD Contents
NNT/iRYS generates the following IODs:

SC – Secondary Capture
CT – Computed Tomography
DX – Direct Radiology
IO – Intra Oral

Used abbreviations are:

ALWAYS the module or attribute shall always be present with value

ANAP Attribute Not Always Present
EMPTY Attribute is sent without a value
AUTO the attribute value is generated automatically
USER the attribute value source is explicit user input
MWL the attribute is derived from the HIS/RIS’ Modality worklist

8.2 Data Dictionary

8.2.1 CT Image IOD Modules
Module Name Presence of module
Patient Always
General Study Always
General Series Always
Frame of reference Always
General Equipment Always
General Image Always
Image Plane Always
Image Pixel Always
CT Image Always
SOP Common Always
VOI Lut Always
Overlay ANAP

8.2.2 SC Image IOD Modules

Module Name Presence of module
Patient Always
General Study Always
General Series Always
SC Equipment Always
General Image Always
Image Pixel Always
SC Image Always
SOP Common Always
VOI Lut Always
Overlay ANAP

8.2.3 DX Image IOD Modules

Module Name Presence of module
Patient Always
General Study Always
General Series Always
DX Series Always
General Equipment Always
 Dicom Conformance Statement - Page 28 of 33

General Image Always

Image Pixel Always
X-Ray Generation Always
DX Anatomy Imaged Always
DX Image Always
DX Detector Always
Acquisition Context Always
SOP Common Always
VOI Lut Always
Overlay ANAP

8.2.4 IO Image IOD Modules

Module Name Presence of module
Patient Always
General Study Always
General Series Always
DX Series Always
Intra-oral Series Always
General Equipment Always
General Image Always
Image Pixel Always
X-Ray Generation Always
DX Anatomy Imaged Always
DX Image Always
DX Detector Always
Intra-oral Image Always
Acquisition Context Always
SOP Common Always
VOI Lut Always
Overlay ANAP

8.2.5 IOD Tags

Patient’s Module Tags
Attribute Name Tag VR Value Presence Source
Patient’s name 0010,0010 PN Always USER or MWL
Patient ID 0010,0020 LO Always USER or MWL
Patient’s Birth Date 0010,0030 DA Always USER or MWL
Patient’s Sex 0010,0040 CS Always MWL
Other Patient IDs 0010,1000 LO Always USER

General Study Module Tags

Attribute Name Tag VR Value Presence Source
Study Instance UID 0020,000D UI Always AUTO or MWL
Study Date 0008,0020 DA Scan date Always AUTO
Study Time 0008,0030 TM Scan time Always AUTO
Referring Physician’s name 0008,0090 PN Always USER or MWL
Study ID 0020,0010 SH Always AUTO
Accession Number 0008,0050 SH Always USER or MWL
Study description 0008,1030 LO Patient note Always USER

General Series Module Tags

Attribute Name Tag VR Value Presence Source
Modality 0008,0060 CS Always AUTO
Series Instance UID 0020,000E UI Always AUTO
Series Number 0020,0011 IS Always AUTO
Laterality 0020,0060 CS CT Only AUTO
Series Date 0008,0021 DA Document Date Always AUTO
Series Time 0008,0031 TM Document Time Always AUTO
Series description 0008,103E LO Document’s note Always USER
Protocol Name 0018,1030 LO Always AUTO
 Dicom Conformance Statement - Page 29 of 33

Patient Position 0018,5100 CS CT Only AUTO

Frame of Reference Module Tags

Attribute Name Tag VR Value Presence Source
Frame of Reference UID 0020,0052 UI CT Only AUTO
Position Reference Indicator 0020,1040 LO void CT Only

General Equipment Module Tags

Attribute Name Tag VR Value Presence Source
Manufacturer 0008,0070 LO Always AUTO
Institution Name 0008,0080 LO Always USER
Station Name 0008,1010 SH Always AUTO
Manufacturer’s model name 0008,1090 LO Always AUTO

General Image Module Tags

Attribute Name Tag VR Value Presence Source
Instance Number 0020,0013 IS Always AUTO
Patient Orientation 0020,0020 CS Always AUTO
Content Date 0008,0023 DA Always AUTO
Content Time 0008,0033 TM Always AUTO
Image Type 0008,0008 CS Always AUTO
Acquisition Number 0020,0012 IS CT Only AUTO
Acquisition Date 0008,0022 DA ANAP AUTO
Acquisition Time 0008,0032 TM ANAP AUTO
Quality Control Image 0028,0300 IS ANAP AUTO
Burned in Annotation 0028,0301 CS ANAP AUTO
Lossy Image Compression 0028,2110 CS 0 ANAP AUTO
Presentation LUT Shape 2050,0020 CS ANAP AUTO

Image Plane Module Tags

Attribute Name Tag VR Value Presence Source
Pixel Spacing 0028,0030 DS Always AUTO
Image Orientation (patient) 0020,0037 DS CT Only AUTO
Image Position (patient) 0020,0032 DS CT Only AUTO
Slice Thickness 0018,0050 DS CT Only AUTO
Slice Location 0020,1041 DS CT Only AUTO

Image Pixel Macro Module Tags

Attribute Name Tag VR Value Presence Source
Sample per Pixel 0028,0002 US Always AUTO
Photometric Interpretation 0028,0004 CS Always AUTO
Rows 0028,0010 US Always AUTO
Columns 0028,0011 US Always AUTO
Bits Allocated 0028,0100 US Always AUTO
Bits Stored 0028,0101 US Always AUTO
High Bit 0028,0102 US Always AUTO
Pixel Data 7FE0,0010 OW Always AUTO
Planar Configuration 0028,0006 US ANAP AUTO
Pixel Aspect ratio 0028,0034 IS ANAP AUTO
Pixel Representation 0028,0103 US Always AUTO

Acquisition Context Module Tags

Attribute Name Tag VR Value Presence Source
Acquisition Context Sequence 0040,0555 SQ ANAP AUTO

CT Image Module Tags

 Dicom Conformance Statement - Page 30 of 33

Attribute Name Tag VR Value Presence Source

Acquisition Number 0020,0012 IS CT Only AUTO
Scan Options 0018,0022 CS CT Only AUTO
Data Collection Diameter 0018,0090 DS ANAP AUTO
Reconstruction Diameter 0018,1100 DS ANAP AUTO
Gantry Detector Tilt 0018,1120 DS CT Only AUTO
Table Height 0018,1130 DS ANAP AUTO
Convolution Kernel 0018,1210 SH CT Only AUTO
CTDI vol 0018,9345 FD CT Only AUTO
CTDI Phantom Type Sequence 0018,9346 SQ CT Only AUTO

SC Module Tags
Attribute Name Tag VR Value Presence Source
Conversion Type 0008,0064 CS ANAP AUTO
Date of Secondary Capture 0018,1012 DA ANAP AUTO
Time of Secondary Capture 0018,1014 TM ANAP AUTO

X-Ray Acquisition Dose Module Tags

Attribute Name Tag VR Value Presence Source
KVP 0018,0060 DS ANAP AUTO
X-ray Tube current 0018,1151 IS ANAP AUTO
Exposure Time 0018,1150 IS ANAP AUTO
Exposure 0018,1152 IS ANAP AUTO
Image and fluoroscopy DAP 0018,115E DS ANAP AUTO

DX Series Module Tags

Attribute Name Tag VR Value Presence Source
Presentation Intent Type 0008,0068 CS For Presentation ANAP AUTO

DX Anatomy Imaged Module Tags

Attribute Name Tag VR Value Presence Source
Image Laterality 0020,0062 CS ANAP AUTO

DX Image Module Tags

Attribute Name Tag VR Value Presence Source
Pixel Intensity Relationship 0028,1040 CS Lin ANAP AUTO
Pixel Intensity Relationship Sign 0028,1041 SS 1 ANAP AUTO
Presentation LUT Shape 2050,0020 CS ANAP AUTO
Lossy Image Compression 0028,2110 CS 00 ANAP AUTO
Burned in Annotation 0028,0301 CS NO ANAP AUTO

DX Detector Module Tags

Attribute Name Tag VR Value Presence Source
Imager Pixel Spacing 0018,1164 DS ANAP AUTO

Digital X-Ray Detector Module Tags

Attribute Name Tag VR Value Presence Source
Detector Type 0018,7004 CS ANAP AUTO

Intra Oral Image Module Tags

Attribute Name Tag VR Value Presence Source
Positioner Type 0018,1508 CS ANAP AUTO
Image Laterality 0020,0062 CS ANAP AUTO
Anatomic Region Sequence 0008,2218 SQ ANAP AUTO
Anatomic Region Modifier Sequence 0008,2220 SQ ANAP AUTO
 Dicom Conformance Statement - Page 31 of 33

Modality LUT Module Tags

Attribute Name Tag VR Value Presence Source
Rescale Intercept 0028,1052 DS ANAP AUTO
Rescale Slope 0028,1053 DS ANAP AUTO
Rescale Type 0028,1054 LO ANAP AUTO

VOI LUT Module Tags

Attribute Name Tag VR Value Presence Source
Window Center 0028,1050 DS Always AUTO
Window Width 0028,1051 DS Always AUTO

SOP Common Module Tags

Attribute Name Tag VR Value Presence Source
SOP Class UID 0008,0016 UI Always AUTO
SOP Instance UID 0008,0018 UI Always AUTO
Specific Character Set 0008,0005 CS Always AUTO
Instance Creation Date 0008,0012 DA Always AUTO
Instance Creation Time 0008,0013 TM Always AUTO
Instance Number 0020,0013 IS Always AUTO

Overlay Plane Module Tags

Attribute Name Tag VR Value Presence Source
Rows 60xx,0010 US ANAP AUTO
Columns 60xx,0011 US ANAP AUTO
Overlay Descriptions 60xx,0022 LO ANAP AUTO
Overlay Type 60xx,0040 CS ANAP AUTO
Overlay Origin 60xx,0050 SS ANAP AUTO
Bits Allocated 60xx,0100 US ANAP AUTO
Bit Position 60xx,0102 US ANAP AUTO
Overlay Data 60xx,3000 OB ANAP AUTO

Other Tags
Attribute Name Tag VR Value Presence Source
Referenced SOP Instance UID 0008,1155 UI ANAP AUTO
Referenced Procedure Step Sequence 0008,1111 SQ ANAP AUTO
Scheduled Procedure Step ID 0040,0009 SH ANAP MWL
Requested Procedure ID 0040,1001 SH ANAP MWL

Private Tags
Attribute Name Tag VR Value Presence Source
Application ID 0019,1002 US CT Only AUTO
Source-Object distance 0019,1003 DS CT Only AUTO
Source-Detector distance 0019,1004 DS CT Only AUTO
Detector pixel width 0019,1005 DS CT Only AUTO
Detector pixel height 0019,1006 DS CT Only AUTO
Correction factor 0019,1007 DS CT Only AUTO
First scout view mA 0019,1009 DS CT Only AUTO
Second scout view mA 0019,100a DS CT Only AUTO
First scout view kV 0019,100b DS CT Only AUTO
Second scout view kV 0019,100c DS CT Only AUTO
Exposure time 0019,000d DS CT Only AUTO
Exposure mAs 0019,000e DS CT Only AUTO
Total exposure time 0019,000f DS CT Only AUTO
Palette scale A 0019,1012 DS CT Only AUTO
Palette scale B 0019,1013 DS CT Only AUTO
HU parameters 0019,101e DS CT Only AUTO
Acquisition dose 0019,101f DS CT Only AUTO
 Dicom Conformance Statement - Page 32 of 33

CTDIw 0019,1020 DS CT Only AUTO

CTDIvol 0019,1021 DS CT Only AUTO
Reconstruction index 0019,1022 IS CT Only AUTO
Modality index 0019,1023 IS CT Only AUTO
Modality name 0019,1024 LO CT Only AUTO
Scan type 0019,1025 IS CT Only AUTO
Dll version 0019,1026 LO Always AUTO
Origin document ID 0019,1027 LO CT Only AUTO
Head document ID 0019,1028 LO CT Only AUTO
Dictionary 0019,1029 OB ANAP AUTO
DLP 0019,1030 LO CT Only AUTO
Dose index 0019,1031 IS CT Only AUTO
Show dose flag 0019,1032 IS CT Only AUTO
Image date and time 0019,1033 DS Always AUTO

8.2.6 MPPS Radiation Dose Tags

Radiation Dose Tags (PS 3.3 rev. 2011 – C.4.16 Radiation Dose)
Attribute Name Tag VR Presence Source
Anatomic Structure, Space or Region 0008,2229 SQ Always/empty AUTO
Total Time of Fluoroscopy 0040,0300 US Always AUTO
Total Number of Exposures 0040,0301 US Always AUTO
Distance Source to Detector 0018,1110 DS Always AUTO
Distance Source to Entrance 0040,0306 DS Always AUTO
Entrance Dose 0040,0302 US Always AUTO
Entrance Dose in mGy 0040,8302 DS Always AUTO
Exposed Area 0040,0303 US Always AUTO
Image and Fluoroscopy Area Dose Product 0018,115E DS Always AUTO
Comments on Radiation Dose 0040,0310 ST Always/empty AUTO
Exposure Dose Sequence 0040,030E SQ Always AUTO
> Radiation Mode 0018,115A CS Always AUTO
> kVp 0018,0060 DS Always AUTO
> X-Ray Tube Current uA 0018,8151 DS Always AUTO
> Exposure Time 0018,1150 IS Always AUTO
> Filter Type 0018,1160 SH Always AUTO
> Filter Material 0018,7050 CS Always AUTO
> Comments on Radiation Dose 0040,0310 ST Always/empty AUTO
 Dicom Conformance Statement - Page 33 of 33

9. Configuration
The configuration of the software application framework is made by the gsqConfig application and is stored in
a local xml file. Only users provided of the correct login/password will be allowed to change the configuration.

9.1 Configuration AE Title/Presentation Address Mapping

The AE Title used by the NNTDicom services is configurable and defaults to 'NNT'. The port is also configurable
and defaults to port 1104.
You need the following information both for SCU and SCP:
 AE Title.
 Host name (to be configured trough the standard NT TCP/IP configuration).
 Port number.

9.2 Configurable Parameters

The following parameters can be configured:
 Maximum number of simultaneous connections [1..256] for SCP.
 If the calling/called Application Entity Title should be checked.
 TCP/IP stack connection timeout

10. Support of Characters Sets

NNT/iRYS offers full support for the following character sets:

Supported character sets

Name Value
Default character repertoire ISO-IR 6
Latin – 1 character repertoire ISO-IR 100
Unicode UTF-8 ISO-IR 192

11. Security profiles

NNT/iRYS does not conform to any defined DICOM Security Profile.