SOCT DICOM Conformance Statement

Manufacturer:
OPTOPOL Technology Sp. z o.o.

ul. Żabia 42
42-400 Zawiercie
POLAND
www.optopol.com
info@optopol.com.pl
DICOM Conformance Statement
REVO nx 130/ REVO nx

REVO FC
REVO 80/ REVO 60
SOCT Copernicus REVO
SOCT Copernicus
REVO 60
Software Version 10.0.0

Rev. A
0197
1 / 41
SOCT DICOM Conformance Statement
Software Version 10.0 rev.A
Symbol Revision Version Description Published on
SOCT DICOM Conformance A 10.0 Initial Version 2021.03.22
Statement Version 10.0 Rev. A
Copyright
© 2020 OPTOPOL Technology Sp. z o.o. All rights reserved.
SOCT DICOM Conformance Statement Version 10.0 Rev. A
Date of issue of manual: March 2021

Date of review: March 2021
For Customer Service or Technical Service contact your authorized dealer of OPTOPOL
Technology Sp. z o.o. Contact details are available on www.optopol.com.
Note: The SOCT Copernicus REVO/SOCT Copernicus/REVO 60/REVO 80/REVO nx/REVO nx

130/REVO FC is hereinafter referred to as the “SOCT”.
The name of application which control scanning device is SOCT.
2 / 41
Contents
1. CONFORMANCE STATEMENT OVERVIEW ................................................................................... 6
2. INTRODUCTION .......................................................................................................................... 7
2.1. Audience .............................................................................................................................. 7
2.2. Remarks................................................................................................................................ 7
2.3. Terms and Definitions .......................................................................................................... 7
2.4. Basics of DICOM Communication ........................................................................................ 9
2.5. Abbreviations ..................................................................................................................... 10
2.6. References.......................................................................................................................... 11
3. NETWORKING ........................................................................................................................... 12
3.1. Implementation model ...................................................................................................... 12
3.1.1. Application Data Flow .............................................................................................. 12
3.1.2. Functional Definitions of AEs ................................................................................... 12
3.1.2.1. WORKLIST-SCU ..................................................................................................... 12
3.1.2.2. STORAGE-SCU....................................................................................................... 12
3.1.3. Sequencing of Real-World Activities ........................................................................ 12
3.2. AE Specifications ................................................................................................................ 12
3.2.1. WORKLIST-SCU ............................................................................................................. 12
3.2.1.1. SOP Classes .......................................................................................................... 12
3.2.1.2. Association Policies .............................................................................................. 13
3.2.1.3. Association Initiation Policy ................................................................................. 13
3.2.1.4. Association Acceptance Policy ............................................................................. 17
3.2.2. STORAGE-SCU ........................................................................................................... 17
3.2.2.1. SOP Classes .......................................................................................................... 17
3.2.2.2. Association Policies .............................................................................................. 18
3.2.2.3. Association Initiation Policy ................................................................................. 18
3.2.2.4. Association Acceptance Policy ............................................................................. 20
3.3. Physical Network Interfaces ............................................................................................... 20
3.3.1. Physical Network Interface....................................................................................... 20
3.3.2. Additional Protocols ................................................................................................. 20
3.3.3. IPv4 and IPv6 Support .............................................................................................. 20
3.4. Configuration ..................................................................................................................... 21
3.4.1. AE Title / Presentation Address Mapping ................................................................ 21
3.4.1.1. Local AE Titles ...................................................................................................... 21
3.4.1.2. Remote AE Titles .................................................................................................. 21
3.4.2. Configurable Parameters .......................................................................................... 21
4. MEDIA STORAGE ....................................................................................................................... 22
5. SUPPORT OF EXTENDED CHARACTER SETS .............................................................................. 23
6. SECURITY................................................................................................................................... 23
6.1. Security Profiles ................................................................................................................. 23
6.2. Association Level Security .................................................................................................. 23
6.3. Application Level Security .................................................................................................. 23
7. ANNEXES ................................................................................................................................... 24
7.1. Created SOP Instances ....................................................................................................... 24
3 / 41
Table A.1: Created SOP Instances ............................................................................................. 24
Table A.2: Ophthalmic Tomography Image Storage ................................................................. 25
Table A.3: Secondary Capture Image Storage .......................................................................... 25
Table A.4: Multi Frame (True Color/ Grayscale Byte) Secondary Capture Image Storage ....... 26
Table A.5: Encapsulated PDF Storage Image Storage ............................................................... 26
Table A.6: Ophthalmic Photography 8-Bit Image Storage ........................................................ 27
7.2. SOP Modules ...................................................................................................................... 28
Table A.7: Patient ...................................................................................................................... 28
Table A.8: General Study .......................................................................................................... 28
Table A.9: Patient Study............................................................................................................ 29
Table A.10: General Series ........................................................................................................ 29
Table A.11: Frame of Reference................................................................................................ 29
Table A.12: General Equipment ................................................................................................ 30
Table A.13: SC Equipment......................................................................................................... 30
Table A.14: General Image........................................................................................................ 30
Table A.15: Image Pixel ............................................................................................................. 31
Table A.16: Cine ........................................................................................................................ 31
Table A.17: Multi Frame ........................................................................................................... 31
Table A.18: Multi Frame Dimensions........................................................................................ 32
Table A.19: Multi Frame Functional Groups ............................................................................. 32
Table A.20: SC Multi-frame Image ............................................................................................ 33
Table A.21: Acquisition Context................................................................................................ 33
Table A.22: Cardiac Synchronization ........................................................................................ 33
Table A.23: Ophthalmic Tomography Acquisition Parameters ................................................. 34
Table A.24: Ophthalmic Tomography Image ............................................................................ 34
Table A.25: Ophthalmic Tomography Parameters .................................................................... 35
Table A.26: Ocular Region Imaged............................................................................................ 36
Table A.27: Modality LUT.......................................................................................................... 36
Table A.28: VOI LUT ................................................................................................................. 36
Table A.29: SOP Common ......................................................................................................... 36
Table A.30: Encapsulated Document ........................................................................................ 37
Table A.31: Ophthalmic Photography Series ............................................................................ 37
Table A.32: Synchronization ..................................................................................................... 37
Table A.33: Ophthalmic Photography Image ............................................................................ 38
Table A.34: Ophthalmic Photography Acquisition Parameters ................................................ 38
Table A.35: Ophthalmic Photographic Parameters .................................................................. 39
Table A.36: Encapsulated Document Series ............................................................................. 39
7.3. Other considerations ......................................................................................................... 40
7.3.1. Usage of Attributes from Received IODs .................................................................. 40
7.3.2. Attribute Mapping .................................................................................................... 40
7.3.3. Coerced / Modified Fields ........................................................................................ 40
7.3.4. Data Dictionary of Private Attributes ....................................................................... 40
7.3.5. Coded Terminology and Templates .......................................................................... 40
7.3.6. Grayscale Image Consistency ................................................................................... 40
7.3.7. Standard Extended / Specialized / Private SOP Classes ........................................... 40
4 / 41
7.3.8. Private Transfer Syntaxes.......................................................................................... 40
7.4. Address of the OPTOPOL Technology and Service Department ........................................ 41
5 / 41
1. CONFORMANCE STATEMENT OVERVIEW
For the Intended Use / Indications for Use, see the The SOCT User manual.
SOCT software supports the following DICOM capabilities:

1 Query an information system for worklists with the patient demographics.
2 Send DICOM objects with examination reports created by the system to a remote storage.
Table 1 provides an overview of the network services supported by SOCT software. The system does not
support any media services.
Table 1: Network services

Network SOP Classes User of service (SCU) Provider of service (SCP)
Transfer
Ophthalmic Tomography Image Storage Yes No
Secondary Capture Image Storage Yes No
Multiframe True Color Secondary Yes No
Capture
Image Storage
Multiframe Grayscale Byte Secondary Yes No
Capture
Image Storage
Encapsulated PDF Storage Image Yes No
Storage
Ophthalmic Photography 8-Bit Image Yes No
Storage
Workflow management
Modality Worklist Information Model – Yes No
FIND
6 / 41
2. INTRODUCTION
This DICOM Conformance Statement specifies the behaviour and functionality
of the SOCT software system, with regard to supported DICOM networking
SOP Classes.
2.1. Audience
This document is written for the people that need to understand how SOCT
software will integrate into their healthcare facility. This includes both those
responsible for overall imaging network policy and architecture, as well as
integrators who need to have a detailed understanding of the DICOM features
of the product. This document contains some basic DICOM definitions so that
any reader may understand how this product implements DICOM features.
However, integrators are expected to fully understand all the DICOM
terminology, how the tables in this document relate to the product’s
functionality, and how that functionality integrates with other devices that
support compatible DICOM features.
2.2. Remarks
The scope of this DICOM Conformance Statement is to facilitate integration
between SOCT software and other DICOM products. The Conformance
Statement should be read and understood in conjunction with the DICOM
Standard. DICOM by itself does not guarantee interoperability. The
Conformance Statement does, however, facilitate a first-level comparison for
interoperability between different applications supporting compatible DICOM
functionality.
This Conformance Statement is not supposed to replace validation with other
DICOM equipment to ensure proper exchange of intended information. In fact,
the user should be aware of the following important issues:
1„ The comparison of different Conformance Statements is just the first step
towards assessing interconnectivity and interoperability between the product
and other DICOM conforming equipment.
2„ Test procedures should be defined and executed to validate the required
level of interoperability with specific compatible DICOM equipment, as
established by the healthcare facility.
2.3. Terms and Definitions

Informal definitions are provided for the following terms used in this
Conformance Statement. The DICOM Standard [DICOM] is the authoritative
7 / 41
source for formal definitions of these terms.
Abstract Syntax: the information agreed to be exchanged between
applications, generally equivalent to a Service/Object Pair (SOP) Class.
Examples: Verification SOP Class, Modality Worklist Information Model Find
SOP Class, Computed Radiography Image Storage SOP Class.
Application Entity (AE): an end point of a DICOM information exchange,
including the DICOM network or media interface software; i. e., the software
that sends or receives DICOM information objects or messages. A single device
may have multiple Application Entities.
Application Entity Title: the externally known name of an Application Entity,
used to identify a DICOM application to other DICOM applications on the
network.
Application Context: the specification of the type of communication used
between Application Entities. Example: DICOM network protocol.
Association: a network communication channel set up between Application
Entities.
Attribute: a unit of information in an object definition; a data element
identified by a tag. The information may be a complex data structure
(Sequence), itself composed of lower level data elements. Examples: Patient ID
(0010,0020), Accession Number (0008,0050), Photometric Interpretation
(0028,0004), Procedure Code Sequence (0008,1032).
Information Object Definition (IOD): the specified set of Attributes that
comprise a type of data object; does not represent a specific instance of the
data object, but rather a class of similar data objects that have the same
properties. The Attributes may be specified as Mandatory (Type 1), Required
but possibly unknown (Type 2), or Optional (Type 3), and there may be
conditions associated with the use of an Attribute (Types 1C and 2C).
Examples: MR Image IOD, CT Image IOD, Print Job IOD.
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
en-coding 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.
8 / 41
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 (OPTOPOL Technology-specific) data element.
Examples: (0010,0020) [Patient ID], (07FE,0010) [Pixel Data], (0019,0210)
[private data element]
Transfer Syntax: the encoding used for exchange of DICOM information
objects and messages. Examples: JPEG compressed (images), little endian
explicit value representation.
Unique Identifier (UID): a globally unique “dotted decimal” string that
identifies a specific object or a class of objects; an ISO-8824 Object Identifier.
Examples: Study Instance UID, SOP Class UID, SOP Instance UID.
Value Representation (VR): the format type of an individual DICOM data
element, such as text, an integer, a person’s name, or a code. DICOM
information objects can be transmitted with either explicit identification of the
type of each data element (Explicit VR), or without explicit identification
(Implicit VR); with Implicit VR, the receiving application must use a DICOM
data dictionary to look up the format of each data element.
2.4. 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,
9 / 41
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 in-formation).
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.
2.5. Abbreviations
The following list illustrates all abbreviations that are used in this document.
ACSE Association Control Service Element
AE Application Entity
CD Compact Disc
CD-R Compact Disc – Recordable
CT Computer Tomography
DICOM Digital Imaging and Communications in Medicine
DIMSE DICOM Message Service Element
ID Identification / Identifier
10 / 41
IOD Information Object Definition
Ipv4 Internet Protocol version 4
Ipv6 Internet Protocol version 6
ISO International Standards Organization
JPEG Joint Photographic Experts Group
MR Magnetic Resonance
MWL Modality Worklist Management
PDF Portable Document Format
PDU Protocol Data Unit
SCP Service Class Provider
SCU Service Class User
SOP Service Object Pair
TCP/IP Transmission Control Protocol / Internet Protocol
UID Unique Identifier
VM Value Multiplicity
VR Value Representation
2.6. References
NEMA PS3 Digital Imaging and Communications in Medicine (DICOM)

Standard, available free at https://www.dicomstandard.org/
11 / 41
3. NETWORKING
3.1. Implementation model
3.1.1. Application Data Flow

Conceptually, the networking services which are implemented in the SOCT
software system may be modeled as the following separate AEs.
3.1.2. Functional Definitions of AEs
3.1.2.1. WORKLIST-SCU
WORKLIST-SCU is working in the SOCT software application background and
queries MWL provider for new data repeatedly every 10 seconds. When new
patient demographic data is found, it is inserted into the work manager list
within the application.
3.1.2.2. STORAGE-SCU
STORAGE-SCU is activated automatically when the patient's examination is
finished or manually. In both cases, a new instance of the Secondary Capture
Image Storage SOP Class is created which is then sent to a remote AE.
3.1.3. Sequencing of Real-World Activities

All SCU activities are initiated in the user interface. For each remote AE, a new
background is started which allows for multiple associations at the same time.
3.2. AE Specifications
3.2.1. WORKLIST-SCU
3.2.1.1. SOP Classes

WORKLIST-SCU provides standard conformance to the following DICOM SOP
classes.
12 / 41
Table 2: SOP Classes for AE WORKLIST SCU
SOP Class Name SOP Class UID SCU SCP
Modality Worklist Information Model – FIND 1.2.840.10008.5.1.4.31 Yes No
3.2.1.2. Association Policies
• General
WORKLIST-SCU initiates but never accepts associations. The DICOM standard
application context name, which is always proposed, is:
Table 3: DICOM Application Context for AE WORKLIST SCU

Application context name 1.2.840.10008.3.1.1.1
The maximum PDU size is 16384 bytes.

SOP Class extended negotiation is not supported.
• Number of Associations
Table 4: Number of Associations as an Association Initiator for AE WORKLIST-SCU

Maximum number of simultaneous associations 1
• Asynchronous Nature
Asynchronous mode of operation is not supported
• Implementation Identifying Information
Table 5: DICOM Implementation Class and Version for AE WORKLIST-SCU

Implementation Class UID 1.2.276.0.7230010.3.0.3.6.1
Implementation Version Name OFFIS_DCMTK_361
3.2.1.3. Association Initiation Policy

WORKLIST-SCU attempts to initiate a new association for the Modality Worklist
Information Model – FIND SOP Class each time the application background
process wants to send a query. Background process has to be activated in
application DICOM configuration pages.
13 / 41
• Activity – System sends a query and shows matches
• Description and Sequencing of Activities

WORKLIST-SCU sends a query to a selected remote AE and puts the matching
worklist entries (if any) in the work manager list. For each query to be
performed, a single attempt will be made. If the send fails, no error message
will be reported to the user, but the queries will be continued in normal
manner repeatedly every 10 seconds.
• Proposed Presentation Contexts
Table 6: Proposed Presentation Contexts for AE WORKLIST-SCU and Real-World Activity ‘System Sends a Query and
Shows Matches
Abstract syntax Transfer syntax Extended
Name UID Name List UID List Role negotiation
Modality
Worklist Implicit VR Little Endian 1.2.840.10008.1.2
Information 1.2.840.10008. Explicit VR Little Endian 1.2.840.10008.1.2.1
Model - FIND 5.1.4.31 Explicit VR Big Endian 1.2.840.10008.1.2.2 SCU None
• Extended Negotiation
No extended negotiation is performed.
• SOP Specific Conformance to Modality Worklist SOP Class
WORKLIST-SCU provides standard conformance to the Modality Worklist
Information Model – FIND SOP Class as an SCU.
Unexpected attributes returned in a C-FIND response are ignored in the same
manner as requested (optional) return attributes not returned by the SCP.
Non-matching responses returned by the SCP due to unsupported matching
keys are not filtered locally by the WORKLIST-SCU and thus will still be shown
in the patient list. No attempt is made to filter out duplicate responses.
No cancel requests are ever issued.
Specific Character Set (0008,0005) will never be included in the query. If
present in the response, its element value will be used to identify character
sets other than the default character set for display. Please note, that
following character sets are supported: ISO-8859-1, ISO-8859-2, ISO-8859-5,
ISO-8859-7, ISO-8859-9 and UTF-8. If another specific character set is used,
the worklist entry can be incorrectly displayed.
The WORKLIST-SCU application entity uses the following attributes from the
Modality Worklist Information Model.
Table 7: Request Identifiers for AE WORKLIST-SCU

Attribute Tag Types of Matching
14 / 41
Accession Number (0008,0050) Universal Matching
Patient ID (0010,0020) Universal Matching
Patient Name (0010,0010) Universal Matching
Patient Birth Date (0010,0030) Universal Matching
Patient Sex (0010,0040) Universal Matching
Patient Comments (0010,4000) Universal Matching
Ethnic Group (0010,2160) Universal Matching
Additional Patient History (0010,21B0) Universal Matching
Visit Comments (0038,4000) Universal Matching
Referring Physician Name (0008,0090) Universal Matching
Institution Name (0008,0080) Universal Matching
Study Instance UID (0020,000d) Universal Matching
Requested Procedure ID (0040,1001) Universal Matching
Requested Procedure Description (0032,1060) Universal Matching
Scheduled Procedure Step Sequence (0040,0100) Universal Matching
Modality >(0008,0060) Universal Matching
Scheduled Station AE Title >(0040,0001) Universal Matching
Scheduled Station Name >(0040,0010) Universal Matching
Scheduled Procedure Step Start Date >(0040,0002) Universal Matching
Scheduled Procedure Step Start Time >(0040,0003) Universal Matching
Scheduled Procedure Step Location >(0040,0011) Universal Matching
Scheduled Procedure Step ID >(0040,0009) Universal Matching
Scheduled Procedure Step Description >(0040,0007) Universal Matching
• Presentation Context Acceptance Criterion

WORKLIST-SCU does not accept associations.
• Transfer Syntax Selection Policies
If offered a choice of transfer syntaxes in the accepted presentation contexts,
the default behaviour of WORKLIST-SCU is to prefer the explicit VR transfer
syntax with the byte order matching the local machine byte order, i.e. little
endian on a Windows PC. If this transfer syntax is not available, the explicit VR
transfer syntax with opposite byte order is selected.
If this is also unavailable, implicit VR little endian is selected. Finally, any
matching presentation context is accepted independent of the transfer syntax.
15 / 41
• Response Status
WORKLIST-SCU will behave as described in the table below when receiving the
C-FIND response command message.
Table 8: Response Status Handling Behaviour for AE WORKLIST-SCU and Real-World Activity ‘System Sends a Query
and Shows Matches'
Service Error
Status Further Meaning Code Behaviour
Refused Out of resources A7xx This is treated as a permanent failure.
Error Identifier does not match SOP class A9xx This is treated as a permanent failure.
Unable to process Cxxx This is treated as a permanent failure.
Matching terminated due to cancel Should never occur since cancel
Cancel request FE00 requests are never issued.
Current query is completed successfully;
Matching is complete - No final resulting list of worklist entries is
Success identifier is supplied 0000 presented to the user.
Matches are continuing – Current
match is supplied and any optional Current match is added to the internal
keys were supported in the same list of worklist entries but not yet
Pending manner as required keys FF00 presented to the user.
Matches are continuing – Warning
that one or more optional keys were Current match is added to the internal
not supported for existence and/or list of worklist entries but not yet
matching for this identifier FF01 presented to the user.
16 / 41
Table 9: Communication Failure Behaviour for AE WORKLIST-SCU and Real-World Activity ‘System Sends a Query and
Shows Matches'
Exception Behaviour
TCP/IP connection could not be established
within the specified time range. Unable to Application try connect again after 10s.
initialize network connection
Association could not be established between
SCU and MWL SCP. Unable to negotiate Application try connect again after 10s.
association
MWL SCP server does not respond to C-ECHO
message. Could not process C-ECHO with the Application try connect again after 10s.
server
There is no uncompressed presentation context
for Modality Worklist Root FIND provided by Application try connect again after 10s.
MWL SCP
3.2.1.4. Association Acceptance Policy

WORKLIST-SCU does not accept associations.
3.2.2. STORAGE-SCU
3.2.2.1. SOP Classes

STORAGE-SCU provides standard conformance to the following DICOM SOP
classes.
Table 10: SOP Classes for AE STORAGE-SC

SOP Class Name SOP Class UID SCU SCP
Ophthalmic Tomography Image Storage 1.2.840.10008.5.1.4.1.1.77.1.5.4 Yes No
Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7 Yes No
Multiframe True Color Secondary Capture
1.2.840.10008.5.1.4.1.1.7.4 Yes No
Image Storage
Multiframe Grayscale Byte Secondary
1.2.840.10008.5.1.4.1.1.7.2 Yes No
Capture Image Storage
Encapsulated PDF Storage Image Storage 1.2.840.10008.5.1.4.1.1.104.1 Yes No
Ophthalmic Photography 8-Bit Image
1.2.840.10008.5.1.4.1.1.77.1.5.1 Yes No
Storage
17 / 41
3.2.2.2. Association Policies
• General
STORAGE-SCU initiates but never accepts associations. The DICOM standard
application context name, which is always proposed, is:
Table 11: DICOM Application Context for AE STORAGE-SCU

Application context name 1.2.840.10008.3.1.1.1
The maximum PDU size is 16384 bytes.

SOP Class extended negotiation is not supported.
• Number of Associations
Table 12: Number of Associations as an Associations Initiator for AE STORAGE-SCU

Maximum number of simultaneous associations 1
• Asynchronous Nature
Asynchronous mode of operation is not supported.
• Implementation Identifying Information
Table 13: DICOM Implementation Class and Version for AE STORAGE-SCU

Implementation Class UID 1.2.276.0.7230010.3.0.3.6.1
Implementation Version Name OFFIS_DCMTK_361
3.2.2.3. Association Initiation Policy

STORAGE-SCU attempts to initiate a new association each time the system
creates an in-stance and wants to send it.
• Activity – System creates new instance and sends it
• Description of Sequencing of Activities

STORAGE-SCU sends a newly created instance to a selected remote AE. For
each instance to be transferred, a single attempt will be made. If the send fails,
no retry will be per-formed but an error message will be reported to the user.
• Proposed Presentation Contexts
18 / 41
Table 14: Proposed Presentation Contexts for AE STORAGE-SCU and Real-World Activity ‘System Creates New Instance
and Sends It’
Abstract syntax Transfer syntax Ext.
negotiatio
Name UID Name List UID List Role n
SecondaryCapt 1.2.840.100
ure 08.5.1.4.1.1. Explicit VR Little Endian 1.2.840.10008.1.2.1 SCU None
ImageStorage 7
• Extended Negotiation
No extended negotiation is performed.
• SOP Specific Conformance to Storage SOP Class
STORAGE-SCU provides standard conformance to the Storage Service Class as
an SCU.
• Presentation Context Acceptance Criterion
STORAGE-SCU does not accept associations.
• Transfer Syntax Selection Policies
If offered a choice of transfer syntaxes in the accepted presentation contexts,
the default behaviour of STORAGE-SCU is to prefer the transfer syntax that is
used for the DICOM file stored on the local system. If this transfer syntax is not
available, an explicit VR uncompressed transfer syntax is selected. If this is also
unavailable, implicit VR little endian is selected. Finally, any matching
presentation context is accepted independent of the transfer syntax.
The default behaviour may be modified by changing the configuration of
STORAGE-SCU.
• Response Status
STORAGE-SCU will behave as described in the table below when receiving the
C-STORE response command message.
Table 15: Response Status Handling Behaviour for AE STORAGE-SCU and Real-World Activity ‘System Creates New
Instance and Sends It’
Service Error
Status Further Meaning Code Behaviour
Refused Out of resources A7xx This is treated as a permanent failure.
Error Data set does not match SOP class A9xx This is treated as a permanent failure.
Cannot understand Cxxx This is treated as a permanent failure.
Warning Bxxx This is treated as a permanent failure.
The DICOM instance was successfully
Success 0000 received by the remote AE.
19 / 41
Table 16: Communication Failure Behaviour for AE STORAGE-SCU and Real-World Activity ‘System Creates New
Instance and Sends It’
Exception Behaviour
TCP/IP connection could not be established
An error message is reported to the user
within the specified time range. Unable to
interface.
initialize network connection
Association could not be established between
SCU and Store SCP. Unable to negotiate
interface.
association
STORE SCP server does not respond to C-ECHO
message. Could not process C-ECHO with the
interface.
server
There is no presentation context for a given
abstract syntax. Server does not support An error message is reported to the user
requested dicom functionality. Presentation interface.
context not accepted.
Sending STORE request failed. Failed to store An error message is reported to the user
dicom data on the server. interface.
3.2.2.4. Association Acceptance Policy

STORAGE-SCU does not accept associations.
3.3. Physical Network Interfaces
3.3.1. Physical Network Interface

The DICOM interface of SOCT software is indifferent to the physical medium
over which TCP/IP is used.
3.3.2. Additional Protocols

When hostnames rather than IP addresses are used in the configuration to
specify presentation addresses for remote AEs, the application is dependent
on the name resolution mechanism of the underlying operating system.
3.3.3. IPv4 and IPv6 Support

SOCT software DICOM interface only supports IPv4 connections.
20 / 41
3.4. Configuration
The configuration can be changed by the user in the preferences window.
Details are described in the SOCT software Instruction Manual.
3.4.1. AE Title / Presentation Address Mapping

The Calling AE Title of the local AEs is configurable in the preferences window.
The mapping of the logical name by which remote AEs are described in the
user interface to Called AE Titles as well as presentation address (hostname or
IP address and port number) is configurable in the preferences window.
3.4.1.1. Local AE Titles
Table 17: AE Title Configuration Table

Application Entity Default AE Title Default TCP/IP Port
WORKLIST-SCU EMPTY 5678
STORAGE-SCU EMPTY 5678
3.4.1.2. Remote AE Titles

The AE Title, hostname or IP address, and port number of remote AEs are
configured in the preferences window.
3.4.2. Configurable Parameters

Concerning the WORKLIST-SCU application entity, the following parameters are
configurable.
Table 18: Configurable Parameters for AE WORKLIST-SCU

Parameter Configurable Default Value
Time-out waiting for response
No unlimited
to TCP/IP connect request
Time-out for ACSE messages No 30 sec.
Time-out for DIMSE messages No unlimited
Maximum PDU size the AE can
No 16384 bytes
receive
Concerning the STORAGE-SCU application entity, the following parameters are

21 / 41
configurable.
Table 19; Configurable Parameters for AE STORAGE-SCU

Parameter Configurable Default Value
Time-out waiting for response
No unlimited
to TCP/IP connect request
Time-out for ACSE messages No 30 sec.
Time-out for DIMSE messages No unlimited
Maximum PDU size the AE can No 16384 bytes

receive
4. MEDIA STORAGE
SOCT software does not support any media services.
22 / 41
5. SUPPORT OF EXTENDED CHARACTER SETS
SOCT software supports following character sets for the created SOP instances.
Table 20: Extended character sets

Name DICOM Charset
default ISO_IR 192
ISO Latin 1 ISO_IR 100
Cyrillic ISO_IR 144
Greek ISO_IR 126
UNICODE ISO_IR 192
6. SECURITY
6.1. Security Profiles

SOCT software does not support any security profiles.
6.2. Association Level Security

SOCT software does not support any association level security.
6.3. Application Level Security

SOCT software does not support any application level security.
23 / 41
7. ANNEXES
7.1. Created SOP Instances

SOCT software creates objects containing a report page/images of the selected
examination.
The following tables use a number of abbreviations.
The abbreviations used in the "Presence of …" column are:
VNAP Value Not Always Present (attribute sent zero length if no value is present)
ANAP Attribute Not Always Present
ALWAYS Always Present
EMPTY Attribute is sent without a value
The abbreviations used in the "Source" column:
MWL the attribute value source Modality Worklist
USER the attribute value source is from User input
AUTO the attribute value is generated automatically
MPPS the attribute value is the same as that use for Modality Performed Procedure Step
CONFIG the attribute value source is a configurable parameter
Note
All dates and times are encoded in the local configured calendar and time.
Table A.1: Created SOP Instances
Storage IOD Ophthalmic Secondary Multiframe Multiframe Encapsulated Ophthalmic

Tomography Capture True Color Grayscale Byte PDF Storage Photography
Image Storage Image Storage Secondary Secondary Image Storage 8-Bit Image
Capture Capture Storage
Image Storage Image Storage
1.2.840.10008
1.2.840.10008.5. 1.2.840.10008. 1.2.840.10008. 1.2.840.10008. 1.2.840.10008. .5.
SOP Class UID
1.4.1.1.77.1.5.4 5.1.4.1.1.6.2 5.1.4.1.1.7.4 5.1.4.1.1.7.2 5.1.4.1.1.104.1 1.4.1.1.77.1.5.
1
Modality OCT OCT/OP OCT OCT OCT/OP OP
Reports N/A Colour N/A N/A Colour N/A
Only Colour Colour Colour

Tomogram greyscale and and and N/A N/A
images greyscale greyscale greyscale
24 / 41
Only Colour Colour
Series greyscale N/A and and N/A N/A
images greyscale greyscale
Fundus Photo N/A N/A N/A N/A N/A Colour
Table A.2: Ophthalmic Tomography Image Storage

Presence
IE Module Reference
of Module
Patient Patient Table A.7 ALWAYS
General Study Table A.8 ALWAYS
Study
Patient Study Table A.9 ALWAYS
Series General Series Table A.10 ALWAYS
Equipment General Equipment Table A.12 ALWAYS
Image Pixel Table A.15 ALWAYS
Multi-frame Functional Groups Table A.19 ALWAYS
Multi-frame Dimensions Table A.18 ALWAYS
Acquisition Context Table A.21 ALWAYS
Cardiac Synchronization Table A.22 ALWAYS
Image
Ophthalmic Tomography Image Table A.24 ALWAYS
Ophthalmic Tomography Acquisition Parameters Table A.23 ALWAYS
Ophthalmic Tomography Parameters Table A.25 ALWAYS
Ocular Region Imaged Table A.26 ALWAYS
SOP Common Table A.29 ALWAYS
Table A.3: Secondary Capture Image Storage

Presence
IE Module Reference
of Module
Study
25 / 41
General Equipment Table A.12 ALWAYS
Equipment
SC Equipment Table A.13 ALWAYS
General Image Table A.14 ALWAYS
Image Modality LUT Table A.27 ALWAYS
VOI LUT Table A.28 ALWAYS
Table A.4: Multi Frame (True Color/ Grayscale Byte) Secondary Capture
Image Storage
Presence
IE Module Reference
of Module
Study
Equipment
Frame of reference Frame of reference Table A.11 ALWAYS
Cine Table A.16 ALWAYS
Multi-frame Table A.17 ALWAYS
Image
Multi-frame Functional Groups Table A.19 ALWAYS
Multi-frame Dimensions Table A.18 ALWAYS
SC Multi-frame Image Table A.20 ALWAYS
Table A.5: Encapsulated PDF Storage Image Storage

Presence
IE Module Reference
of Module
Study General Study Table A.8 ALWAYS
26 / 41
Series Encapsulated Document Series Table A.36 ALWAYS
Equipment
Encapsulated Encapsulated Document Table A.30 ALWAYS
Document SOP Common Table A.29 ALWAYS
Table A.6: Ophthalmic Photography 8-Bit Image Storage

Presence
IE Module Reference
of Module
Study
General Series Table A.10 ALWAYS
Series
Ophthalmic Photography Series Table A.31 ALWAYS
Frame of Reference Synchronization Table A.32 ALWAYS
Equipment General Equipment Table A.12 ALWAYS
Cine Table A.16 ALWAYS
Multi-frame Table A.17 ALWAYS
Image Ophthalmic Photography Image Table A.33 ALWAYS
Ocular Region Imaged Table A.26 ALWAYS
Ophthalmic Photography Acquisition Parameters Table A.34 ALWAYS
Ophthalmic Photographic Parameters Table A.35 ALWAYS
27 / 41
7.2. SOP Modules
Table A.7: Patient

Presence
Attribute Name Tag VR Value Source
of Value
From Modality Worklist or user
input. Values supplied via
Modality Worklist will be
Patient Name (0010,0010) PN entered as received. Values VNAP MWL/USER
supplied via user input will
contain all 5 components in 3
groups (some possibly empty).
Patient ID (0010,0020) LO VNAP MWL/USER
input.
Patient Birth Date (0010,0030) DA VNAP MWL/USER
input
Patient Sex (0010,0040) CS VNAP MWL/USER
input
Ethnic Group (0010,2160) SH VNAP MWL/USER
input
Patient Comments (0010,4000) LT VNAP MWL/USER
input
Table A.8: General Study

Presence
of Value
From Modality Worklist or

Study Instance UID (0020,000d) UI ALWAYS MWL/AUTO
generated by device
Study Date (0008,0020) DA <yyyyMMdd> ALWAYS AUTO

Study Time (0008,0030) TM <HHmmss.zzz> ALWAYS AUTO
Referring Physician
(0008,0090) PN From Modality Worklist VNAP MWL
Name
Study ID (0020,0010) SH Generated by device ALWAYS AUTO
Accession Number (0008,0050) SH VNAP MWL/USER
input
From Modality Worklist
Study Description (0008,1030) LO Scheduled Procedure Step VNAP MWL
Description (0040, 0007) Value.
28 / 41
Table A.9: Patient Study
Presence
of Value
Calculated from Patient's Birth
Patient Age (0010,1010) AS VNAP AUTO
Date input and Study Date.
Additional Patient
(0010,21b0) LT From user input Disease VNAP MWL/USER
History
Table A.10: General Series

Presence
of Value
Modality (0008,0060) CS OPT or OP ALWAYS AUTO
Series Instance UID (0020,000e) UI Generated by device ALWAYS AUTO
Series Number (0020,0011) IS Generated by device ALWAYS AUTO

Laterality (0020,0060) CS Generated by device VNAP AUTO
Series Date (0008,0021) DA <yyyyMMdd> ALWAYS AUTO
Series Time (0008,0031) TM <HHmmss.zzz> ALWAYS AUTO
Performing Physician From Configuration Login user
(0008,1050) PN ANAP CONFIG
Name name
Protocol Name (0018,1030) LO Generated by device ALWAYS AUTO
Series Description (0008,103e) LO Generated by device ALWAYS AUTO
From Configuration Login user
Operators Name (0008,1070) PN VNAP CONFIG
name
Table A.11: Frame of Reference

Presence
of Value
Frame Of Reference UID (0020,0052) UI Generated by device ALWAYS AUTO
Position Reference
(0020,1040) LO EMPTY AUTO
Indicator
29 / 41
Table A.12: General Equipment
Presence
of Value
Manufacturer (0008,0070) LO Optopol Technology Sp. z o.o. ALWAYS AUTO
Institution Address (0008,0081) ST From Configuration ALWAYS CONFIG

Institution Name (0008,0080) LO From Configuration ALWAYS CONFIG
Station Name (0008,1010) SH From Configuration VNAP CONFIG
Institutional
(0008,1040) LO From Configuration ALWAYS CONFIG
Department Name
Manufacturer Model
(0008,1090) LO Generated by device ALWAYS AUTO
Name
Device Serial Number (0018,1000) LO Generated by device ALWAYS AUTO
Software Versions (0018,1020) LO Generated by device ALWAYS AUTO
Table A.13: SC Equipment

Presence
of Value
Conversion Type (0008,0064) CS DI ALWAYS AUTO
Table A.14: General Image

Presence
of Value
Instance Number (0020,0013) IS Generated by device ALWAYS AUTO
Patient Orientation (0020,0020) CS L\P or F\P or L\F ANAP AUTO
Content Date (0008,0023) DA <yyyyMMdd> ALWAYS AUTO
Content Time (0008,0033) TM <HHmmss.zzz> ALWAYS AUTO
(1st ) ORIGINAL or DERIVED
(2nd) PRIMARY or SECONDARY
Image Type (0008,0008) CS (3rd) EMPTY ALWAYS AUTO
(4 ) Scan Pattern (3D, Radial,
th
etc.)
Acquisition Number (0020,0012) IS 1 ALWAYS AUTO
Acquisition Date Time (0008,002a) DT <yyyyMMddHHmmss.zzz> ALWAYS AUTO
30 / 41
Only for reports of tomograms
Images In Acquisition (0020,1002) IS ANAP AUTO
Generated by device
Image Comments (0020,4000) LT Generated by device ANAP AUTO
Only for monochrome images
Presentation LUT Shape (2050,0020) CS ANAP AUTO
IDENTITY
Table A.15: Image Pixel

Presence
of Value
Pixel Aspect Ratio (0028,0034) IS Generated by device ANAP AUTO
Bits Allocated (0028,0100) US 8 ALWAYS AUTO
Bits Stored (0028,0101) US 8 ALWAYS AUTO
High Bit (0028,0102) US 7 ALWAYS AUTO
Pixel Representation (0028,0103) US 0 ALWAYS AUTO
Samples Per Pixel (0028,0002) US 1 or 3 (OP) ALWAYS AUTO
Photometric
(0028,0004) CS RGB or MONOCHROME2 ALWAYS AUTO
Interpretation
Planar Configuration (0028,0006) US 0 ALWAYS AUTO
Rows (0028,0010) US Generated by device ALWAYS AUTO
Columns (0028,0011) US Generated by device ALWAYS AUTO
Pixel Data (7fe0,0010) OW Generated by device ALWAYS AUTO
Table A.16: Cine

Presence
of Value
Frame Time (0018,1063) DS Generated by device ALWAYS AUTO
Table A.17: Multi Frame

Presence
of Value
Number Of Frames (0028,0008) IS Generated by device ALWAYS AUTO
Frame Increment
(0028,0009) AT 0018, 1063 or 0008, 002A ALWAYS AUTO
Pointer
31 / 41
Table A.18: Multi Frame Dimensions
Presence
of Value
Dimension Organization
(0020,9221) SQ EMPTY AUTO
Sequence
Dimension Index
Sequence
Table A.19: Multi Frame Functional Groups

Presence
of Value
Shared Functional
(5200,9229) SQ ALWAYS AUTO
Groups Sequence
>Frame Anatomy
Sequence
Generated by device Same as
>>Frame Laterality (0020,9072) CS ANAP AUTO
Laterality
>>Anatomic Region
Sequence
>>>Code Value (0008,0100) SH T-AA000 ANAP AUTO
>>>Coding Scheme
(0008,0102) SH SRT ANAP AUTO
Designator
>>>Code Meaning (0008,0104) LO EYE ANAP AUTO
>Referenced Image
Sequence
>Derivation Image
Sequence
>Ophthalmic Frame
Location Sequence
Per Frame Functional
Groups Sequence
>Pixel Measures
Sequence
>>Pixel Spacing (0028,0030) DS Generated by device ANAP AUTO
>>Slice Thickness (0018,0050) DS Generated by device ANAP AUTO
>Frame Content
Sequence
>>Stack ID (0020,9056) SH Generated by device ALWAYS AUTO
>>In Stack Position
(0020,9057) UL Generated by device ALWAYS AUTO
Number
32 / 41
>Plane Position
Sequence
>>Image Position
(0020,0032) DS Generated by device ALWAYS AUTO
Patient
>Plane Orientation
Sequence
>>Image Orientation
(0020,0037) DS Generated by device ALWAYS AUTO
Patient
Number Of Frames (0028,0008) IS Generated by device ALWAYS AUTO
Table A.20: SC Multi-frame Image

Presence
of Value
Burned In Annotation (0028,0301) CS NO ALWAYS AUTO
Rescale Intercept (0028,1052) DS 0 - Only for greyscale images ALWAYS AUTO
Rescale Slope (0028,1053) DS 1 - Only for greyscale images ALWAYS AUTO
Rescale Type (0028,1054) LO US - Only for greyscale images ALWAYS AUTO
Table A.21: Acquisition Context

Presence
of Value
Acquisition Context
Sequence
Table A.22: Cardiac Synchronization

Presence
of Value
Cardiac Synchronization
(0018,9037) CS NONE ALWAYS AUTO
Technique
33 / 41
Table A.23: Ophthalmic Tomography Acquisition Parameters
Presence
of Value
Axial Length Of The Eye (0022,0030) FL Generated by device ALWAYS AUTO
Horizontal Field Of View (0022,000c) FL Generated by device ALWAYS AUTO
Refractive State
(0022,001b) SQ Generated by device ALWAYS AUTO
Sequence
Emmetropic
(0022,000a) FL Generated by device ALWAYS AUTO
Magnification
Intra Ocular Pressure (0022,000b) FL Generated by device ALWAYS AUTO
Pupil Dilated (0022,000d) CS Generated by device ALWAYS AUTO
Table A.24: Ophthalmic Tomography Image

Presence
of Value
(1st ) ORIGINAL or DERIVED
(2nd) PRIMARY or SECONDARY
Image Type (0008,0008) CS (3rd) EMPTY ALWAYS AUTO
(4th) Scan Pattern (3D, Rarial,
etc.)
Samples per Pixel (0028,0002) US 1 or 3 ALWAYS AUTO

Acquisition Duration (0018,9073) FD Generated by device ALWAYS AUTO
Acquisition Number (0020,0012) IS 1 ALWAYS AUTO
Photometric
(0028,0004) CS RGB or MONOCHROME2 ALWAYS AUTO
Interpretation
Bits Allocated (0028,0100) US 8 ALWAYS AUTO
Bits Stored (0028,0101) US 8 ALWAYS AUTO
High Bit (0028,0102) US 7 ALWAYS AUTO
Presentation LUT Shape (2050,0020) CS IDENTITY ALWAYS AUTO
Lossy Image
(0028,2110) CS 00 or 01 ALWAYS CONFIG
Compression
Lossy Image
DS 17 ANAP AUTO
Compression Ratio (0028,2112)
Lossy Image CS ISO_10918_1 ANAP AUTO
34 / 41
Compression Method (0028,2114)

Concatenation Frame
(0020,9228) UL 0 ALWAYS AUTO
Offset Number
In Concatenation
(0020,9162) US 1 ALWAYS AUTO
Number
In Concatenation Total
(0020,9163) US 1 ALWAYS AUTO
Number
Table A.25: Ophthalmic Tomography Parameters

Presence
of Value
Acquisition Device Type
Code Sequence
>Code Value (0008,0100) SH A-00FBE ALWAYS AUTO
>Coding Scheme
(0008,0102) SH SRT ALWAYS AUTO
Designator
Optical Cohenrence
>Code Meaning (0008,0104) LO ALWAYS AUTO
Tomography Scanner
Light Path Filter Type

Stack Code Sequence
Detector Type (0018,7004) CS CCD ALWAYS AUTO
Illumination Wave
(0022,0055) FL 830 ALWAYS AUTO
Length
Illumination Power (0022,0056) FL 985 or 1500 ALWAYS AUTO
Illumination Bandwidth (0022,0057) FL 50 ALWAYS AUTO
Depth Spatial
Resolution
Maximum Depth
Distortion
Along Scan Spatial
Resolution
Maximum Along Scan
Distortion
Across Scan Spatial
Resolution
Maximum Across Scan
Distortion
35 / 41
Table A.26: Ocular Region Imaged
Presence
of Value
Image Laterality (0020,0062) CS R or L ALWAYS AUTO
Anatomic Region
Sequence
T-AA000 or T-AA610 or T-AA612
>Code Value (0008,0100) SH ALWAYS AUTO
or T-AA630 or T-AA200
>Coding Scheme
(0008,0102) SH SRT ALWAYS AUTO
Designator
Eye or Retina or Fovea centralis
>Code Meaning (0008,0104) LO ALWAYS AUTO
or Optic nerve head or Cornea
Table A.27: Modality LUT

Presence
of Value
Rescale Intercept (0028,1052) DS 0 ALWAYS AUTO
Rescale Slope (0028,1053) DS 1 ALWAYS AUTO
Rescale Type (0028,1054) LO US ALWAYS AUTO
Table A.28: VOI LUT

Presence
of Value
Window Center (0028,1050) DS Only if greyscale image 128 ANAP AUTO
Window Width (0028,1051) DS Only if greyscale image 256 ANAP AUTO
Table A.29: SOP Common

Presence
of Value
1.2.840.10008.5.1.4.1.1.77.1.5.4
or 1.2.840.10008.5.1.4.1.1.7
or 1.2.840.10008.5.1.4.1.1.7.4
SOP Class UID (0008,0016) UI or 1.2.840.10008.5.1.4.1.1.7.2 ALWAYS AUTO
or 1.2.840.10008.5.1.4.1.1.104.1
or
1.2.840.10008.5.1.4.1.1.77.1.5.1
36 / 41
SOP Instance UID (0008,0018) UI Generated by device ALWAYS AUTO
ISO_IR 192 or ISO_IR 100 or

Specific Character Set (0008,0005) CS ANAP CONFIG
ISO_IR 192
Timezone Offset From U
(0008,0201) SH Generated by device ALWAYS AUTO
TC
Instance Creation Date (0008,0012) DA Generated by device ALWAYS AUTO
Instance Creation Time (0008,0013) TM Generated by device ALWAYS AUTO
Table A.30: Encapsulated Document

Presence
of Value
Document Title (0042,0010) ST EMPTY AUTO
Image Laterality (0020,0062) CS R or L ALWAYS AUTO
MIME Type of
(0042,0012) LO application/pdf ALWAYS AUTO
Encapsulated Document
Encapsulated Document (0042,0011) ox ALWAYS AUTO
Table A.31: Ophthalmic Photography Series

Presence
of Value
Modality (0008,0060) CS OP ALWAYS AUTO
Table A.32: Synchronization

Presence
of Value
Synchronization Frame (0020,0200) UI 1.2.840.10008.15.1.1 ALWAYS AUTO
37 / 41
of Reference UID
Synchronization Trigger (0018,106A) CS NO TRIGGER ALWAYS AUTO
Acquisition Time
(0018,1800) CS N ALWAYS AUTO
Synchronized
Table A.33: Ophthalmic Photography Image

Presence
of Value
Image Type (0008,0008) CS ORIGINAL/PRIMARY//COLOR ALWAYS AUTO
Instance Number (0020,0013) IS 1 ALWAYS AUTO
Samples per Pixel (0028,0002) US 3 ALWAYS AUTO
Photometric
(0028,0004) CS RGB ALWAYS AUTO
Interpretation
Only for colour images
Planar Configuration (0028,0006) US ANAP AUTO
0
Content Time (0008,0033) TM <hhmmss.zzz> ALWAYS AUTO
Lossy Image
(0028,2110) CS 00 or 01 ALWAYS CONFIG
Compression
Lossy Image
DS 17 ANAP AUTO
Compression Ratio (0028,2112)
Lossy Image
CS ISO_10918_1 ANAP AUTO
Compression Method (0028,2114)
Generated by device :
Pixel Spacing (0028,0030) DS ALWAYS AUTO
pixelW\pixelH
Table A.34: Ophthalmic Photography Acquisition Parameters

Presence
of Value
Patient Eye Movement
CS NO ALWAYS AUTO
Commanded (0022,0005)
Horizontal Field of View FL Horizontal FoV in degrees ALWAYS AUTO
(0022,000C)
Refractive State
(0022,001B) SQ EMPTY AUTO
Sequence
Emmetropic (0022,000A) FL EMPTY AUTO
38 / 41
Magnification
Intra Ocular Pressure FL EMPTY AUTO

(0022,000B)
Pupil Dilated CS EMPTY AUTO
(0022,000D)
Table A.35: Ophthalmic Photographic Parameters

Presence
of Value
Acquisition Device Type
SQ ALWAYS AUTO
Code Sequence (0022,0015)
>Code Value SH R-1021A ALWAYS AUTO
(0008,0100)
>Coding Scheme
SH SRT ALWAYS AUTO
Designator (0008,0102)
>Code Meaning (0008,0104) LO Fundus Camera ALWAYS AUTO
Illumination Type Code
SQ EMPTY AUTO
Sequence (0022,0016)
Light Path Filter Type
SQ EMPTY AUTO
Stack Code Sequence (0022,0017)
Image Path Filter Type
Stack Code Sequence
Lenses Code Sequence SQ EMPTY AUTO
(0022,0019)
Detector Type (0018,7004) CS CCD ALWAYS AUTO
Table A.36: Encapsulated Document Series

Presence
of Value
Modality (0008,0060) CS Generated by device ALWAYS AUTO
Series Instance UID (0020,000E) UI <yyyyMMdd> ALWAYS AUTO
Series Number (0020,0011) IS <HHmmss.zzz> ALWAYS AUTO
Protocol Name (0018,1030) LO Generated by device ALWAYS AUTO
Series Description (0008,103e) LO Generated by device ALWAYS AUTO
39 / 41
7.3. Other considerations
7.3.1. Usage of Attributes from Received IODs

SOCT software does not receive any IODs.
7.3.2. Attribute Mapping

SOCT software does not receive any IODs.
7.3.3. Coerced / Modified Fields

SOCT software does not modify any fields.
7.3.4. Data Dictionary of Private Attributes

There are no additional private attributes added to created SOP instances.
7.3.5. Coded Terminology and Templates

SOCT software does not use or support any coded terminology or templates.
7.3.6. Grayscale Image Consistency

SOCT software does not make use of the DICOM Grayscale Standard Display
Function.
7.3.7. Standard Extended / Specialized / Private SOP Classes

SOCT software uses a standard extended SOP class for the Encapsulated PDF
and Secondary Capture Image IOD by adding a private data module. See PDF
section for details.
The system does not support any specialized or private SOP classes.
7.3.8. Private Transfer Syntaxes

SOCT software does not use or support any private transfer syntaxes.
40 / 41
7.4. Address of the OPTOPOL Technology and Service Department
Our service department or authorised representatives will furnish you with additional
information.
Address of the OPTOPOL Technology and Service Department:
OPTOPOL Technology Sp z o.o.

Żabia 42
42-400 Zawiercie
Poland
Tel.: + 48 32 670 91 73
E-mail: info@optopol.com.pl or service@optopol.com.pl
www.optopol.com
41 / 41

SOCT DICOM Conformance Statement

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SOCT DICOM Conformance Statement

Uploaded by

Copyright:

Available Formats

Manufacturer:

OPTOPOL Technology Sp. z o.o.

DICOM Conformance Statement

REVO nx 130/ REVO nx

Software Version 10.0.0

© 2020 OPTOPOL Technology Sp. z o.o. All rights reserved.

SOCT DICOM Conformance Statement Version 10.0 Rev. A

Date of issue of manual: March 2021

Note: The SOCT Copernicus REVO/SOCT Copernicus/REVO 60/REVO 80/REVO nx/REVO nx

The name of application which control scanning device is SOCT.

SOCT software supports the following DICOM capabilities:

Table 1: Network services

2.3. Terms and Definitions

2.4. Basics of DICOM Communication

NEMA PS3 Digital Imaging and Communications in Medicine (DICOM)

3.1. Implementation model

3.1.1. Application Data Flow

3.1.2. Functional Definitions of AEs

3.1.3. Sequencing of Real-World Activities

3.2.1.1. SOP Classes

3.2.1.2. Association Policies

Table 3: DICOM Application Context for AE WORKLIST SCU

The maximum PDU size is 16384 bytes.

Table 4: Number of Associations as an Association Initiator for AE WORKLIST-SCU

Table 5: DICOM Implementation Class and Version for AE WORKLIST-SCU

3.2.1.3. Association Initiation Policy

• Description and Sequencing of Activities

Table 7: Request Identifiers for AE WORKLIST-SCU

• Presentation Context Acceptance Criterion

3.2.1.4. Association Acceptance Policy

3.2.2.1. SOP Classes

Table 10: SOP Classes for AE STORAGE-SC

Table 11: DICOM Application Context for AE STORAGE-SCU

The maximum PDU size is 16384 bytes.

Table 12: Number of Associations as an Associations Initiator for AE STORAGE-SCU

• Implementation Identifying Information

Table 13: DICOM Implementation Class and Version for AE STORAGE-SCU

3.2.2.3. Association Initiation Policy

• Description of Sequencing of Activities

3.2.2.4. Association Acceptance Policy

3.3. Physical Network Interfaces

3.3.1. Physical Network Interface

3.3.2. Additional Protocols

3.3.3. IPv4 and IPv6 Support

3.4.1. AE Title / Presentation Address Mapping

3.4.1.1. Local AE Titles

Table 17: AE Title Configuration Table

3.4.1.2. Remote AE Titles

3.4.2. Configurable Parameters

Table 18: Configurable Parameters for AE WORKLIST-SCU

Concerning the STORAGE-SCU application entity, the following parameters are

Table 19; Configurable Parameters for AE STORAGE-SCU

Time-out for ACSE messages No 30 sec.

Time-out for DIMSE messages No unlimited

Maximum PDU size the AE can No 16384 bytes

Table 20: Extended character sets

6.1. Security Profiles

6.2. Association Level Security

6.3. Application Level Security

7.1. Created SOP Instances

Table A.1: Created SOP Instances

Storage IOD Ophthalmic Secondary Multiframe Multiframe Encapsulated Ophthalmic

Modality OCT OCT/OP OCT OCT OCT/OP OP

Reports N/A Colour N/A N/A Colour N/A