Issued July 30, 2021 by ProKnow DICOM Agent v1.2.0

1. Conformance Statement Overview

ProKnow DICOM Agent is a locally installed Windows application which facilitates the transfer of patient data from on-premise clinical systems to the cloud-based ProKnow RT-PACS. In addition to transferring data to ProKnow, ProKnow DICOM Agent also enables the storage of received data to the local file system.

Although ProKnow DICOM Agent supports network transfer of all standard SOP classes, ProKnow limits support to common radiotherapy types. Refer to the ProKnow DICOM Conformance Statement for more information.

Table 1-1 provides an overview of the network services supported by integration of ProKnow DICOM Agent with ProKnow.

Table 1-1: Network Services

SOP Class	User of Service (SCU)	Provider of Service SCP
Transfer
CT Image Storage	No	Yes
MR Image Storage	No	Yes
Positron Emission Tomography (PET) Image Storage	No	Yes
RT Structure Set Storage	No	Yes
RT Plan Storage	No	Yes
Varian Ethos Private RT Plan Storage	No	Yes
RT Ion Plan Storage	No	Yes
RT Dose Storage	No	Yes
Spatial Registration Storage	No	Yes
Query/Retrieve
none
Workflow Management
none
Print Management
none

2. Table of Contents

• 1. Conformance Statement Overview
• 2. Table of Contents
  • 2.1. List of Tables
• 3. Introduction
  • 3.1. Revision History
  • 3.2. Audience
  • 3.3. Remarks
  • 3.4. Terms and Definitions
  • 3.5. Basics of DICOM Communication
  • 3.6. Abbreviations
  • 3.7. References
• 4. Networking
  • 4.1. Implementation Model
    • 4.1.1. Application Data Flow
    • 4.1.2. Functional Definition of AEs
      • 4.1.2.1. Functional Definition of Storage AE
    • 4.1.3 Sequencing of Real-World Activities
  • 4.2. AE Specifications
    • 4.2.1 AE Specification for Storage AE
      • 4.2.1.1 SOP Classes
      • 4.2.1.2 Association Policies
        • 4.2.1.2.1 General
        • 4.2.1.2.2 Number of Associations
        • 4.2.1.2.3 Asynchronous Nature
      • 4.2.1.3 Association Initiation Policy
      • 4.2.1.4 Association Acceptance Policy
        • 4.2.1.4.1 Activity - Receive Storage Request
          • 4.2.1.4.1.1 Description and Sequencing of Activities
          • 4.2.1.4.1.2 Accepted Presentation Contexts
            • 4.2.1.4.1.2.1 Extended Negotiation
          • 4.2.1.4.1.3 SOP Specific Conformance
            • 4.2.1.4.1.3.1 SOP Specific Conformance to Storage SOP Classes
            • 4.2.1.4.1.3.2 Presentation Context Acceptance Criterion
            • 4.2.1.4.1.3.3 Transfer Syntax Selection Policies
            • 4.2.1.4.1.3.4 Response Status
• 5. Media Interchange
• 6. Transformation of DICOM to CDA
• 7. Support Character Sets
• 8. Security
  • 8.1. Security Profiles
  • 8.2. Association Level Security
  • 8.3. Application Level Security
• 9. Annexes
  • 9.1. IOD Contents
    • 9.1.1. Created SOP Instances
    • 9.1.2. Usage of Attributes From Received SOP Instances
      • 9.1.2.1. Common Module Implementations
    • 9.1.3. Attribute Mapping
    • 9.1.4. Coerced/Modified Fields
  • 9.2. Data Dictionary of Private Attributes
  • 9.3. Coded Terminology Templates
  • 9.4. Greyscale Image Consistency
  • 9.5. Standard Extended/Specialized/Private SOP Classes
  • 9.6. Private Transfer Syntaxes

2.1. List of Tables

Table Number	Table Name
1-1	Network Services
3-1	Revision History
3-2	Terms and Definitions
3-3	Abbreviations
3-4	References
4-1	SOP Classes for Storage AE
4-2	Maximum PDU Size Received as an SCP for Storage
4-3	Number of Associations as an SCP for Storage
4-4	Asynchronous Nature as an SCP for Storage
4-5	Acceptable Presentation Contexts for Storage SCP and Receive Storage Request
4-6	Response Status for Storage SCP and Receive Storage Request
C.7.1.1-Import	Patient Module (C.7.1.1) Import
C.7.2.1-Import	General Study Module (C.7.2.1) Import
C.7.3.1-C.8.8.1-Import	General Series Module (C.7.3.1) / RT Series Module (C.8.8.1) Import
C.12.1-Import	SOP Common Module (C.12.1) Import

3. Introduction

3.1. Revision History

Table 3-1: Revision History

Document Revision	Date of Issue	Description of Change
A	February 26, 2021	Initial release
B	July 30, 2021	Add support for Varian Ethos Private RT Plan Storage SOP class

3.2. Audience

This document is written for the people that need to understand how ProKnow DICOM Agent 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.

3.3. Remarks

The scope of this DICOM conformance statement is to facilitate integration between ProKnow DICOM Agent and other DICOM products. The conformance statement should be read and understood in conjunction with the DICOM standard. DICOM by itself does not guarantee interoperability. The conformance statement does, however, facilitate a first-level comparison for interoperability between different applications supporting compatible DICOM functionality. This conformance statement is not supposed to replace validation with other DICOM equipment to ensure proper exchange of intended information. In fact, the user should be aware of the following important issues:

• The comparison of different conformance statements is just the first step towards assessing interconnectivity and interoperability between the product and other DICOM conformant equipment.
• Test procedures should be defined and executed to validate the required level of interoperability with specific compatible DICOM equipment, as established by the healthcare facility.

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.

Table 3-2: Terms and Definitions

Term	Definition
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 (AET)	The externally known name of an Application Entity, used to identify a DICOM application to other DICOM applications on the network.
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 Entity (IE)	That portion of information defined by a Composite IOD which is related to one specific class of Real-World Object. There is a one-to-one correspondence between Information Entities and entities in the DICOM Application Model.
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.
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. Example: 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.
Type (Attribute Type)	A numeric flag used to specify whether an Attribute is mandatory or optional: 1 = Attribute is mandatory and must contain a non-zero length value 2 = Attribute must be included in data set, although it is allowed to have no value or a zero-length value 3 = Attribute is optional
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.

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.

3.6. Abbreviations

Table 3-3: Abbreviations

AE	Application Entity
AET	Application Entity Title
CT	Computed Tomography
DICOM	Digital Imaging and Communications in Medicine
IE	Information Entity
IOD	Information Object Definition
ISO	International Organization for Standards
MR	Magnetic Resonance Imaging
NEMA	National Electrical Manufacturers Association
PACS	Picture Archiving and Communication System
PDU	Protocol Data Unit
PET	Positron Emission Tomography
RT	Radiotherapy
SCU	Service Class User
SCP	Service Class Provider
SOP	Service-Object Pair
SRO	Spatial Registration Object
UID	Unique Identifier
VR	Value Representation

3.7. References

Table 3-4: References

NEMA PS3

Digital Imaging and Communications in Medicine (DICOM) Standard, available free at https://www.dicomstandard.org/

4. Networking

4.1. Implementation Model

4.1.1. Application Data Flow

The diagram below illustrates the interactions ProKnow DICOM Agent makes with the DICOM world.

4.1.2. Functional Definition of AEs

4.1.2.1. Functional Definition of Storage AE

The AEs labeled as “PROKNOW_SCP_1”, “PROKNOW_SCP_2”, “PROKNOW_SCP_3” in Figure 4-1 are examples of the storage provider (C-STORE SCP) AEs that the user may configure in ProKnow DICOM Agent. The user may configure multiple AEs by providing a name, AE title, port, ProKnow domain (base URL), and ProKnow API credentials file for each AE. The user also chooses the storage destination(s) for each AE by enabling ProKnow cloud storage and/or local file storage. For ProKnow cloud storage, the user selects a workspace within the ProKnow domain. For local file storage, the user selects a root folder. For security purposes, that root folder must be within the home directory of the user with which ProKnow DICOM Agent was installed.

These C-STORE SCP AEs receive the transmitted DICOM objects and store them locally in temporary files.

If local file storage is enabled, the temporary files are copied to the configured root folder and organized into a folder hierarchy by Patient ID and Study Instance UID. Image sets are further organized into folders labeled by Modality and Series Instance UID. Files are labeled by Modality and SOP Instance UID.

If cloud storage is enabled, the temporary files are uploaded to ProKnow. For each received DICOM object, ProKnow initiates a background processing task to update its database. Once all received DICOM objects for an association are uploaded, ProKnow DICOM Agent queries ProKnow to obtain the processing results for the entire association and logs these results.

4.1.3 Sequencing of Real-World Activities

All SCP activities are performed asynchronously in the background and not dependent on any sequencing.

4.2. AE Specifications

4.2.1 AE Specification for Storage AE

4.2.1.1 SOP Classes

This Application Entity provides Standard Conformance to the following Storage SOP Classes.

Table 4-1: SOP Classes for Storage AE

SOP Class	SOP Class UID	User of Service (SCU)	Provider of Service (SCP)
Verification	1.2.840.10008.1.1	No	Yes
CT Image Storage	1.2.840.10008.5.1.4.1.1.2	No	Yes
MR Image Storage	1.2.840.10008.5.1.4.1.1.4	No	Yes
Positron Emission Tomography (PET) Image Storage	1.2.840.10008.5.1.4.1.1.128	No	Yes
RT Structure Set Storage	1.2.840.10008.5.1.4.1.1.481.3	No	Yes
RT Plan Storage	1.2.840.10008.5.1.4.1.1.481.5	No	Yes
Varian Ethos Private RT Plan Storage	1.2.246.352.70.1.70	No	Yes
RT Ion Plan Storage	1.2.840.10008.5.1.4.1.1.481.8	No	Yes
RT Dose Storage	1.2.840.10008.5.1.4.1.1.481.2	No	Yes
Spatial Registration Storage	1.2.840.10008.5.1.4.1.1.66.1	No	Yes

4.2.1.2 Association Policies

4.2.1.2.1 General

The Storage SCP AE accepts but never initiates associations.

Table 4-2: Maximum PDU Size Received as an SCP for Storage

Maximum PDU size received

256 KB

4.2.1.2.2 Number of Associations

Table 4-3: Number of Associations as an SCP for Storage

Maximum number of simultaneous associations

Unlimited

4.2.1.2.3 Asynchronous Nature

The Storage SCP AE will perform asynchronous operations window negotiation.

Table 4-4: Asynchronous Nature as an SCP for Storage

Maximum number of asynchronous operations invoked	Unlimited
Maximum number of asynchronous operations performed	Unlimited

4.2.1.3 Association Initiation Policy

The Storage SCP AE does not initiate associations.

4.2.1.4 Association Acceptance Policy

4.2.1.4.1 Activity - Receive Storage Request

4.2.1.4.1.1 Description and Sequencing of Activities

As instances are received, they are stored locally in temporary files.

If local file storage is enabled, the temporary file is copied to the configured root folder and organized into a folder hierarchy by Patient ID and Study Instance UID. Image sets are further organized into folders labeled by Modality and Series Instance UID. Files are labeled by Modality and SOP Instance UID.

If cloud storage is enabled, the temporary file is uploaded to the configured ProKnow domain and workspace. For each received DICOM object, ProKnow initiates a background processing task to update its database. Once all received DICOM objects for an association are uploaded, ProKnow DICOM Agent queries ProKnow to obtain the processing results for the entire association and logs these results.

4.2.1.4.1.2 Accepted Presentation Contexts

Table 4-5: Acceptable Presentation Contexts for Storage SCP and Receive Storage Request

Presentation Context Table
Abstract Syntax		Transfer Syntax		Role		Extended Negotiation
Name	UID	Name List	UID List
See Table 4-1	See Table 4-1	Implicit VR Little Endian	1.2.840.10008.1.2	SCP	None
		Explicit VR Little Endian	1.2.840.10008.1.2.1

4.2.1.4.1.2.1 Extended Negotiation

No extended negotiation is performed, though Storage SCP:

• is a Level 2 Storage SCP (Full - does not discard any data elements)
• does not support digital signatures
• does not coerce any received data elements

4.2.1.4.1.3 SOP Specific Conformance

4.2.1.4.1.3.1 SOP Specific Conformance to Storage SOP Classes

STORAGE-SCP provides standard conformance to the Storage Service Class.

4.2.1.4.1.3.2 Presentation Context Acceptance Criterion

Storage SCP will always accept any Presentation Context for the supported SOP Classes with the supported Transfer Syntaxes. More than one proposed Presentation Context will be accepted for the same Abstract Syntax if the Transfer Syntax is supported, whether or not it is the same as another Presentation Context.

4.2.1.4.1.3.3 Transfer Syntax Selection Policies

The first transfer syntax encountered in the configuration file, which matches a transfer syntax offered for a given presentation context, will be selected as the accepted transfer syntax for that presentation context.

4.2.1.4.1.3.4 Response Status

Storage SCP will behave as described in the table below when generating the C-STORE response command message.

Table 4-6: Response Status for Storage SCP and Receive Storage Request

Service Status	Further Meaning	Error Code	Reason
Error	Class Instance Conflict	0119	The received DICOM did not contain a data set
Error	Processing Failure	0110	An application exception occurred
Success	Success	0000	The data set was successfully stored as temporary file prior to uploading to ProKnow and/or storing locally

5. Media Interchange

ProKnow DICOM Agent does not provide any media interchange services.

6. Transformation of DICOM to CDA

ProKnow DICOM Agent does not support any Structured Reporting (SR) objects.

7. Support Character Sets

ProKnow DICOM Agent does not support extended character sets.

8. Security

ProKnow DICOM Agent does not claim conformance to any of the Security and System Management Profiles defined in the DICOM Standard. That being said, data security is one of the most important aspects of the ProKnow DICOM Agent design. All data transmission both to and from the Internet (including calls to the ProKnow REST API to upload DICOM files) is encrypted using secure HTTP access (HTTPS) and all communication between servers is encrypted using HTTPS or SSL.

8.1. Security Profiles

ProKnow DICOM Agent provides the ability to perform automated anonymization based upon user-configured anonymization rules. See Configuring Anonymization for more details. Table 8-1 contains attributes added to datasets to indicate that anonymization was performed.

Table 8-1

Attribute Name	Tag	VR	Value
Patient Identity Removed	(0012,0062)	CS	YES
De-identification Method	(0012,0063)	LO	ProKnow DICOM Agent vX.Y.Z where “vX.Y.Z” is the application version

8.2. Association Level Security

ProKnow DICOM Agent does not support Association Level Security.

8.3. Application Level Security

The ProKnow DICOM Agent design includes several security features:

• ProKnow DICOM Agent restricts resources and file access to the home directory of the user account that was used to install ProKnow DICOM Agent including:
  • The database.
  • The folder from which to browse for ProKnow credentials files.
  • The temporary folder used to store all received DICOM instances.
  • The local storage folder to which to save received DICOM instances.
  • The log files.
• All data transmission to and from the Internet (including calls to the ProKnow REST API to upload DICOM files) is encrypted using secure HTTP access (HTTPS).
• Access to the web-based Management Console is only available on the local machine (localhost).

9. Annexes

9.1. IOD Contents

9.1.1. Created SOP Instances

None.

9.1.2. Usage of Attributes From Received SOP Instances

9.1.2.1. Common Module Implementations

Patient Module (C.7.1.1) Import

Attribute Name	Tag	Type	Notes
Patient's Name	(0010,0010)	2	Used with Patient ID (0010,0020) for patient folder name for local storage.
Patient ID	(0010,0020)	2	Used with Patient’s Name (0010,0010) for patient folder name for local storage. Also used for debug-level logging.

General Study Module (C.7.2.1) Import

Attribute Name	Tag	Type	Notes
Study Instance UID	(0020,000D)	1	Used for study folder name for local storage.

General Series Module (C.7.3.1) / RT Series Module (C.8.8.1) Import

Attribute Name	Tag	Type	Notes
Modality	(0008,0060)	1	Used along with SOP Instance UID (0008,0018) for filename for local storage. Also used for summary (information-level) logging and debug-logging.
Series Instance UID	(0020,000E)	1	Used to count images in image sets for summary (information-level) logging.

SOP Common Module (C.12.1) Import

Attribute Name	Tag	Type	Notes
SOP Class UID	(0008,0016)	1	Used to count images in image sets for summary logging.
SOP Instance UID	(0008,0018)	1	Used along with Modality (0008,0060) for filename for local storage. Also used for debug-level logging.

9.1.3. Attribute Mapping

ProKnow DICOM Agent does not perform any attribute mapping.

9.1.4. Coerced/Modified Fields

ProKnow DICOM Agent does not coerce nor modify any of the input fields.

9.2. Data Dictionary of Private Attributes

ProKnow DICOM Agent does not export any private attributes.

9.3. Coded Terminology Templates

ProKnow DICOM Agent does used not support coded terminology or templates.

9.4. Greyscale Image Consistency

ProKnow DICOM Agent does not provide support for the DICOM Grayscale Standard Display Function.

9.5. Standard Extended/Specialized/Private SOP Classes

ProKnow DICOM Agent supports extensions of the standard SOP classes specified in section 1. It does not support any specialized or private SOP classes.

9.6. Private Transfer Syntaxes

ProKnow DICOM Agent does not support any private transfer syntaxes.