NO. PAGE: Table provides an overview of the network services supported by the MDR Video. Table Network Services

Transcription

1

2 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 2 of ONFORMANE STATEMENT OVERVIEW MDR Video is an analog video input image capture and transfer system. aptured images, either cine loops or single frame images, may be sent to the internal D/DVD recorder and optionally up to two network archives. The MDR Video may also be configured for Modality Worklist, Modality Performed Procedure Step, or Storage ommitment. A DIOM Image viewer may also be written to the D/DVD allowing image review on personal computers that do not have a DIOM viewer application. Table provides an overview of the network services supported by the MDR Video. Table Network Services SOP lasses User of Service (SU) Provider of Service (SP) Transfer Secondary apture Image Storage Yes Option Multi-frame Grayscale Byte Secondary apture Image Storage Yes Option Multi-frame True olor Secondary apture Image Storage Yes Option Ultrasound Image Storage Yes Option Ultrasound Image Storage (Retired) Yes Option Ultrasound Multi-frame Image Storage Yes Option Ultrasound Multi-frame Image Storage (Retired) Yes Option Nuclear Medicine Image Storage (Retired) Yes Option omputed Radiography Image Storage Yes Option X-Ray Angiographic Image Storage Yes Option X-Ray Radiofluoroscopic Image Storage Yes Option Basic Voice Audio Waveform Storage Option Option Workflow Management Modality Worklist Information Model FIND Option No Modality Performed Procedure Step SOP lass Option No Storage ommitment Push Model SOP lass Option No

3 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 3 of 54 Table provides an overview of the Media Storage Application Profiles supported by the MDR Video. Table Media Services Media Storage Application Profile Write Files (FS) Read Files (FSR) ompact Disk Recordable General Purpose D-R Interchange Yes Yes Magneto-Optical Disk T-MR 2.3 GB MOD No No DVD Standard General Purpose DVD-RAM Yes Yes General Purpose DVD Interchange with JPEG Yes Yes USB General Purpose USB Media Interchange with JPEG Yes Yes

4 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 4 of 54 TABLE OF ONTENTS 1.0 ONFORMANE STATEMENT OVERVIEW INTRODUTION Audience Remarks Terms and Definitions Basics of DIOM ommunication Abbreviations References NETWORKING Implementation Model Application Data Flow Functional Definition of AEs Functional Definition of Storage SU Application Entity Functional Definition of Workflow Application Entity Functional Definition of Storage SP Application Entity Sequencing of Real World Activities Workflow Options Query/Use Worklist Select Worklist Item Open Exam omplete Acquisition Store Acquired Images (optional step) Storage ommitment (optional step) Application Entity Specifications Storage lass SU Application Entity Specification SOP lasses Association Policies General Number of Associations Asynchronous Nature Implementation Identifying Information Association Initiation Policy Activity Send Exam to Archive Server Association Acceptance Policy Activity Receive Storage ommitment Response Workflow Management Application Entity Specification SOP lasses Association Policies General Number of Associations Asynchronous Nature Implementation Identifying Information Association Initiation Policy Activity - onnectivity Verification Activity - Worklist Update...25

5 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 5 of Activity Acquire Images Association Acceptance Policy Storage SP Application Entity Specification SOP lasses Association Policies General Number of Associations Asynchronous Nature Implementation Identifying Information Association Initiation Policy Association Acceptance Policy Activity Receive Storage Request Network Interfaces Physical Network Interface Additional Protocols DHP IPv4 and IPv6 Support onfigurable Parameters MEDIA INTERHANGE Implementation Model Application Data Flow Functional Definition of AE s Functional Definition of Media Storage Application Entity Sequencing of Real-World Activities Media Export Media Import File Meta Information AE Specifications Media Storage Application Entity Specifications File Meta Information for Media Storage AE Real-World Activities Activity Send Exam Activity Acquire Images Activity Import Media Storage Application Profiles Options Augmented and Private Application Profiles Media onfiguration SUPPORT OF EXTENDED HARATER SETS SEURITY PROFILES IOD ONTENTS Secondary apture Image IOD Ultrasound Image IOD Ultrasound Image (Retired) IOD Nuclear Medicine Image (Retired) IOD omputed Radiography Image IOD...42

6 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 6 of X-Ray Angiographic Image IOD X-Ray Radiofluoroscopic Image IOD Basic Voice Audio Waveform IOD ommon Modules Modality Specific Modules Storage ommitment Attributes Attribute Mapping Standard Extended/Specialized/Private SOPs Private Transfer Syntaxes...54 LIST OF FIGURES Figure Networking Application Flow Diagram Figure Sequencing onstraints Figure Sequencing of Activity Send Images Figure Sequencing of Activity Receive Storage ommitment Response Figure Sequencing of Activity Worklist Update Figure Sequencing of Activity Acquire Images Figure Media Interchange Application Flow Diagram LIST OF TABLES Table Network Services... 2 Table Media Services... 3 Table SOP lasses for Storage Table Storage SU AE Proposed Presentation ontexts to a Storage lass SP 18 Table Storage SU AE Behavior to Status Returned from SP Table Storage AE ommunication Failure Behavior Table Storage SU AE Behavior to Status Returned from SP Table Storage SU AE ommunication Failure Behavior Table Storage ommitment N-EVENT-REPORT Behavior Table Storage ommitment N-EVENT-REPORT Response Status Table Association Rejection Reasons Table Acceptable Presentation ontexts for Storage SU AE Table SOP lasses for Workflow Management Application Entity Table Proposed Presentation ontext for onnectivity Verification Table Proposed Presentation ontext for Worklist Update Table Workflow Management -FIND Response Status Handling Behavior Table Workflow Management AE ommunication Failure Behavior Table Modality Worklist Information Model Attributes Table Proposed Presentation ontext for MPPS Table Workflow Management N-REATE/N-SET Response Status Handling Behavior Table Workflow Management AE ommunication Failure Behavior Table MPPS N-REATE/N-SET Request Identifier Table SOP lasses Supported by Storage SP AE... 33

7 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 7 of 54 Table Acceptable Presentation ontexts for Storage SP AE Received Storage Request Table Storage SP -STORE Response Status Table Supported System Management Profiles Table Supported System DHP Parameters Table Media Services Table Secondary apture Image SOP Instances Table Multi-frame Grayscale Byte S Image SOP Instances Table Multi-frame True olor S Image SOP Instances Table Ultrasound Image SOP Instances Table Ultrasound Multi-Frame Image SOP Instances Table Ultrasound Image SOP Instances Table Ultrasound Multi-Frame (Retired) Image SOP Instances Table 7.4 Nuclear Medicine Image (Retired) SOP Instances Table 7.5 IOD of reated omputed Radiography Image SOP Instances Table 7.6 X-Ray Angiographic Image SOP Instances Table 7.7 X-Ray Radiofluoroscopic Image SOP Instances Table 7.8 Basic Voice Audio Storage Modules Table Patient Module Attributes Table General Study Module Attributes Table General Series Module Attributes Table General Equipment Module Attribute Table General Image Module Attributes Table Image Pixel Module Attributes Table ine Module Attributes Table Multi-frame Module Attributes Table VOI LUT Module Attributes Table SOP ommon Module Attributes Table Acquisition ontext Module Attributes Table S Equipment Module Attributes Table S Image Module Attributes Table S Multi-frame Image Module Attributes Table S Multi-frame Vector Module Attributes Table US Region alibration Module Attributes Table US Image Module Attributes Table NM Series (Retired) Module Attributes Table NM Image (Retired) Module Attributes Table R Series Module Attributes Table R Image Module Attributes Table X-Ray Image Module Attributes Table X-Ray Acquisition Module Attributes Table XA Positioner Module Attributes Table Waveform Identification Module Attributes Table Waveform Module Attributes Table Storage ommitment Request Action Information SU Attributes Table Attribute Mapping Between Modality Worklist, Image, and MPPS... 54

8 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 8 of INTRODUTION 2.1 Audience This document is written for the people that need to understand how the MDR Video 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 DIOM features of the product. This document contains some basic DIOM definitions so that any reader may understand how this product implements DIOM features. However, integrators are expected to fully understand all the DIOM terminology, how the tables in this document relate to the product s functionality, and how that functionality integrates with other devices that support compatible DIOM features. 2.2 Remarks The scope of this DIOM onformance Statement is to facilitate integration between the NAI Tech Products Medical Digital Recorder (MDR ) Video and other DIOM products. The onformance Statement should be read and understood in conjunction with the DIOM Standard. DIOM by itself does not guarantee interoperability and successful interconnectivity. The onformance Statement does, however, facilitate a first-level comparison for interoperability between different applications supporting compatible DIOM functionality. This onformance Statement is not intended to replace validation with other DIOM equipment to ensure proper exchange of intended information. The user should be aware of the following important issues: The comparison of different conformance statements is just the first step towards assessing interconnectivity between NAI Tech Products Medical Digital Recorder (MDR ) Video and other DIOM conformant equipment. Test procedures should be defined and executed to validate the required level of interoperability with specific compatible DIOM equipment, as established by the healthcare facility. The DIOM standard will evolve to meet the users' future requirements. NAI Tech Products reserves the right to make changes to its products or to discontinue their delivery. 2.3 Terms and Definitions Informal definitions are provided for the following terms used in this onformance Statement. The DIOM Standard is the authoritative source for formal definitions of these terms. Term Abstract Syntax Application Entity (AE) Application Entity Title Application ontext Definition the information agreed to be exchanged between applications, generally equivalent to a Service/Object Pair (SOP) lass. Examples: Verification SOP lass, Modality Worklist Information Model Find SOP lass, omputed Radiography Image Storage SOP lass. an end point of a DIOM information exchange, including the DIOM network or media interface software; i.e., the software that sends or receives DIOM information objects or messages. A single device may have multiple Application Entities. the externally known name of an Application Entity, used to identify a DIOM application to other DIOM applications on the network. the specification of the type of communication used between Application Entities. Example: DIOM network protocol.

9 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 9 of 54 Term Association Attribute Information Object Definition (IOD) Joint Photographic Experts Group (JPEG) Media Application Profile Module Negotiation Presentation ontext Protocol Data Unit (PDU) Security Profile Service lass Provider (SP) Service lass User (SU) Service/Object Pair (SOP) lass Service/Object Pair (SOP) Instance Definition a network communication channel set up between Application Entities. 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 ode Sequence (0008,1032). 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 1 and 2). Examples: MR Image IOD, T Image IOD, Print Job IOD. a set of standardized image compression techniques, available for use by DIOM applications. the specification of DIOM information objects and encoding exchanged on removable media (e.g., Ds) 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. 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. the set of DIOM network services used over an Association, as negotiated between Application Entities; includes Abstract Syntaxes and Transfer Syntaxes. a packet (piece) of a DIOM message sent across the network. Devices must specify the maximum size packet they can receive for DIOM messages. 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 DIOM data. role of an Application Entity that provides a DIOM network service; typically, a server that performs operations requested by another Application Entity (Service lass User). Examples: Picture Archiving and ommunication System (image storage SP, and image query/retrieve SP), Radiology Information System (modality worklist SP). role of an Application Entity that uses a DIOM network service; typically, a client. Examples: imaging modality (image storage SU, and modality worklist SU), imaging workstation (image query/retrieve SU). the specification of the network or media transfer (service) of a particular type of data (object); the fundamental unit of DIOM interoperability specification. Examples: Ultrasound Image Storage Service, Basic Grayscale Print Management. an information object; a specific occurrence of information exchanged in a SOP lass. Examples: a specific x-ray image.

10 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 10 of 54 Tag Term Transfer Syntax Unique Identifier (UID) Value Representation (VR) Definition 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]. the encoding used for exchange of DIOM information objects and messages. Examples: JPEG compressed (images), little endian explicit value representation. 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 lass UID, SOP Instance UID. the format type of an individual DIOM data element, such as text, an integer, a person s name, or a code. DIOM 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 DIOM data dictionary to look up the format of each data element. 2.4 Basics of DIOM ommunication This section describes terminology used in this onformance Statement for the non-specialist. The key terms used in the onformance Statement are highlighted in italics below. This section is not a substitute for training about DIOM, and it makes many simplifications about the meanings of DIOM terms. Two Application Entities (devices) that want to communicate with each other over a network using DIOM 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). DIOM specifies a number of network services and types of information objects, each of which is called an Abstract Syntax for the Negotiation. DIOM 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 ontexts. The receiving Application Entity accepts the Presentation ontexts it supports. For each Presentation ontext, the Association Negotiation also allows the devices to agree on Roles which one is the Service lass User (SU - client) and which is the Service lass Provider (SP - server). Normally the device initiating the connection is the SU, 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. ommon 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.

11 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 11 of 54 Two Application Entities may also communicate with each other by exchanging media (such as a D-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 Abbreviations used in this document are described as follows: Term AR AE ANSI D-R D-RW DIOM DVD+R DVD+RW FS FSR GB HIS IOD ISO MB MDR Video NEMA RIS SP SU SOP UID VR Description American ollege of Radiology Application Entity American National Standards Institute ompact Disk - Recordable ompact Disk - Rewritable Digital Imaging and ommunications in Medicine Digital Video Disk - Recordable Digital Video Disk - Rewritable File Set reator File Set Reader Gigabytes Hospital Information System Information Object Definition International Standards Organization Mega bytes Medical Digital Recorder (NAI Tech Products) National Electrical Manufacturers Association Radiology Information System Service lass Provider Service lass User Service Object Pair Unique Identifier Value Representation 2.6 References Document Type Document Identifier Description ontrolled Document Standard NEMA PS3 The Digital Imaging and ommunications in N Medicine (DIOM) standard, available free at Manual MDR Video Operator Manual Y

12 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 12 of NETWORKING 3.1 Implementation Model Application Data Flow This implementation model uses the following Application Entities: Storage SU Application Entity Workflow Management Application Entity Storage SP Application Entity Send Exam Acquire Images Update Worklist Storage SU Application Entity Workflow Management Application Entity Remote Application Entity Receives Images Remote AE Manages Storage ommitment Remote AE Provides Worklist Items Remote AE Receives MPPS reate/update Add to Local Database Storage SP Application Entity Remote AE Sends Unsolicited Instances DIOM Standard Interface Figure Networking Application Flow Diagram

13 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 13 of 54 The Storage SU Application Entity sends images and audio waveforms to a remote AE. It is associated with the local real-world activities Send Exam and Acquire Images. Send Exam is performed upon user request for selected exams from Exam Manager. Acquire Images will send images to the configured Archive server(s) as they are captured during an exam when activated by user s settings (Archive Mode set to Auto). If the MPPS/Storage ommitment option is installed and configured, the Storage SU AE will request Storage ommitment and if a commitment is successfully obtained will record this information in the local database. The Workflow Application Entity receives Worklist information from and sends MPPS information to a remote AE. It is associated with the local real-world activities Update Worklist and Acquire Images. When the Update Worklist local real-world activity is performed the Workflow Application Entity queries a remote AE for worklist items and provides the set of worklist items matching the query request. Update Worklist is performed as a result of an operator request or can be performed automatically at specific time intervals. When the Acquire Images local real-world activity is performed the Workflow Application Entity creates and updates Modality Performed Procedure Step instances managed by a remote AE. Acquisition of images will result in automated creation of an MPPS Instance. ompletion of the MPPS is performed after the exam is ended. If the option is installed and configured, the Storage SP Application Entity can receive instances from a remote AE and add them to the local database. The user may select them from Exam Manager and queue them for network or media storage Functional Definition of AEs Functional Definition of Storage SU Application Entity A send-job queue entry may be created in one of two ways. Upon the successful creation of a new exam and image capture initiated by the operator, when the archive mode is set to Auto. The user manually selects and exam and queues it for an archive. The existence of a send-job queue entry with associated network destination will activate the Storage SU AE. An association request is sent to the destination AE and upon successful negotiation of a Presentation ontext the image transfer is started. If the association cannot be opened, the related sendjob is set to an error state. The Storage SU AE will try to automatically initiate another association for this send-job Functional Definition of Workflow Application Entity Worklist Update attempts to download a Worklist from a remote server using operator-selected keys. If the Worklist AE establishes an Association to a remote AE, it will transfer all worklist items via the open Association. The results will be displayed in a list, which will be overwritten with the next Worklist Update Functional Definition of Storage SP Application Entity The Storage SP AE waits in the background for connections, will accept associations with Presentation ontexts for SOP lasses of the Storage Service lass, and will store the received instances to the local database where they may subsequently be acted on through the user interface.

14 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 14 of Sequencing of Real World Activities Storage SU AE Workflow Mgmnt AE Department Scheduler Archive 1. Query Worklist 2. Receive Worklist 3. Select Worklist Item 4. Open Exam (reate MPPS) 5. Acquire Images 6. End Exam (Finalize MPPS) 7. Store Acquired Images 8. ommit Acquired Images Workflow Options Figure Sequencing onstraints The operator may create a new exam using either worklist query, automatic character recognition (where the patient name and identification are derived from text contained within the prospective image), operator entry via the display and/or keyboard, or automatically generated name and identification based upon time and date of the exam. Images may be sent to the archive either after the exam is ended, or automatically as they are acquired, or not at all. The workflow illustrated in Figure shows worklist query, and exams sent to the archive after the exam is ended Query/Use Worklist If worklist has been chosen as the method for patient identification the operator may choose to query a Worklist Server AE for an updated worklist or use a previously acquired worklist Select Worklist Item An item from the worklist may be selected via the keyboard or display.

15 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 15 of Open Exam Either Single-Frame or ine images may be acquired. If the MPPS/Storage ommitment option is installed and configured, an MPPS instance will be created after the first image is queued for storage omplete Acquisition User must manually complete exam using a keyboard or display. If the MPPS/Storage ommitment option is installed and configured, the MPPS instance will be finalized Store Acquired Images (optional step) If a send-job queue was previously set up, the images and/or cines may be sent to a Storage SP Storage ommitment (optional step) After the images are sent to an archive, storage commitment may be requested. 3.2 Application Entity Specifications Storage lass SU Application Entity Specification SOP lasses The Storage lass SU AE provides conformance to the following DIOM SOP lasses: Table SOP lasses for Storage SOP lass Name SOP lass UID onformance Level Verification SOP lass Standard Secondary apture Image Storage SOP Standard Extended lass Multi-frame Grayscale Byte S Image Standard Storage SOP lass Multi-frame True olor S Image Storage Standard SOP lass Ultrasound Image Storage SOP lass Standard Extended Ultrasound Image Storage SOP lass Standard Extended (retired) Ultrasound Multi-frame Image Storage SOP Standard Extended lass (retired) Ultrasound Multi-frame Image Storage SOP Standard Extended lass Nuclear Medicine Image Storage SOP Standard Extended lass (retired) omputed Radiography Image Storage Standard Extended SOP lass X-Ray Angiographic Image Storage SOP Standard Extended lass X-Ray Radiofluoroscopic Image Storage Standard Extended SOP lass Basic Voice Audio Waveform Storage Standard

16 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 16 of Association Policies General The DIOM standard application context name for DIOM 3.0 is always proposed: Application ontext Name: Maximum PDU size offered: 32,768 bytes Maximum PDU size accepted: 65,536 bytes Number of Associations The number of simultaneous associations initiated by the Storage SU AE is one per archive destination. The Storage SU AE will also accept associations to receive N-EVENT_REPORT notifications for the Storage ommitment Push Model SOP lass. The other AEs in this device may be simultaneously active, and thus other associations may be open simultaneously Asynchronous Nature The Storage SU AE will not use asynchronous operations window negotiation Implementation Identifying Information Implementation lass UID: dddddddd Implementation Version Name: NAI xxxx Note: is registered by NAI Tech Products with ANSI. dddddddd and xxxx are subject to change with new software releases Association Initiation Policy Activity Send Exam to Archive Server Description and Sequencing of Activities The operator can select an exam in the Exam Manager and queue it for up to two archives. Each request is processed individually. In addition, if the Archive Mode is set to Auto, images will be queued during an open exam as they are captured. The user has the option of deleting the most recently captured image, so queuing is always performed one image behind. The last image is queued when the exam is closed. An Association will be established when images are queued. If more than one image is queued, then multiple -STORE requests will be issued over the same Association. The Association will be closed when there are no more images to send.

17 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 17 of 54 Storage SU AE Image Manager 1. Open Association 2. -STORE 3. -STORE 4. lose Association 5. Open Association 6. N-ATION (Storage ommitment Request) 7. N-EVENT-REPORT 8. lose Association Figure Sequencing of Activity Send Images A possible sequence of interactions between the Storage SU AE and an Image Manager (e.g. a device such as a PAS which supports Storage and Storage ommitment SOP lasses as an SP) is illustrated in Figure 3.2-1: 1. The Storage SU AE opens an association with the Archive. 2. An acquired image is transmitted to the Archive using a -STORE request and the Archive replies with a -STORE response (status success). 3. Another acquired image is transmitted to the Archive using a -STORE request and the Archive replies with a -STORE response (status success). 4. The Storage SU AE closes the association with the Archive. 5. The Storage SU AE opens an association with the Archive. 6. An N-ATION request is transmitted to the Archive to obtain storage commitment of previously transmitted instances. The Archive replies with an N-ATION response indicating the request has been received and is being processed. 7. The Archive immediately transmits an N-EVENT-REPORT request notifying the Storage SU AE of the status of the Storage ommitment Request (sent in step 6 using the N-ATION message). The Storage SU AE replies with an N-EVENT-REPORT response confirming receipt. The Archive could send this message at any time or omit it entirely in favor of transmitting the N-EVENT-REPORT over a separate dedicated association (see note). 8. The Storage SU AE closes the association with Archive. NOTE: Many other message sequences are possible depending on the number of instances to be stored, support for Storage ommitment and when the SP sends the N-EVENT-REPORT. The N-EVENT-REPORT can also be sent over a separate association initiated by Archive (see Section on Activity Receive Storage ommitment Response).

18 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 18 of Proposed Presentation ontexts to an Archive Server One or more Presentation ontexts will be proposed to the SP from Table Table Storage SU AE Proposed Presentation ontexts to a Storage lass SP Presentation ontext Table Abstract Syntax Transfer Syntax Name UID Name List UID List Role omputed Implicit VR Little Endian SU Radiography Explicit VR Little Endian Image Storage Explicit VR Big Endian SOP lass Lossy JPEG 8-bit ompression 50 Lossless JPEG ompression 70 Ultrasound Multi-frame Image Storage SOP lass (Retired) Ultrasound Multi-frame Image Storage SOP lass Nuclear Medicine Image Storage SOP lass (Retired) Ultrasound Image Storage SOP lass (Retired) Ultrasound Image Storage SOP lass Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian Lossy JPEG 8-bit ompression Lossless JPEG ompression 70 Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian Lossy JPEG 8-bit ompression 50 Lossless JPEG ompression 70 Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian Lossy JPEG 8-bit ompression 50 Lossless JPEG ompression 70 Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian Lossy JPEG 8-bit ompression 50 Lossless JPEG ompression 70 Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian SU SU SU SU SU Ext. Neg. None None None None None None

19 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 19 of 54 Presentation ontext Table Abstract Syntax Transfer Syntax Name UID Name List UID List Role Lossy JPEG 8-bit ompression 50 Lossless JPEG ompression 70 Secondary Implicit VR Little Endian SU apture Image Explicit VR Little Endian Storage SOP Explicit VR Big Endian lass Lossy JPEG 8-bit ompression 50 Lossless JPEG ompression 70 Multi-frame Grayscale Byte S Image Storage SOP lass Multi-frame True olor S Image Storage SOP lass X-Ray Angiographic Image Storage SOP lass X-Ray Radiofluroscopic Image Storage SOP lass Basic Voice Audio Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian Lossy JPEG 8-bit ompression Lossless JPEG ompression 70 Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian Lossy JPEG 8-bit ompression 50 Lossless JPEG ompression 70 Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian Lossy JPEG 8-bit ompression 50 Lossless JPEG ompression 70 Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian Lossy JPEG 8-bit ompression 50 Lossless JPEG ompression 70 Implicit VR Little Endian Explicit VR Little Endian SU SU SU SU SU Ext. Neg. None None None None None None

20 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 20 of 54 Abstract Syntax Presentation ontext Table Transfer Syntax Name UID Name List UID List Role Waveform Explicit VR Big Endian Storage Storage Implicit VR Little Endian SU ommitment.20.1 Explicit VR Little Endian Push SOP Explicit VR Big Endian lass SOP Specific onformance to Image Storage SOP lasses All image storage SOP classes supported by the Storage SU AE exhibit the same behavior, and are described together in this section. Service Status Table Storage SU AE Behavior to Status Returned from SP Meaning Error ode Storage AE Behavior Success Normal status 0000 Upon successful data store to an archive server, the Storage SU AE will continue operation without user notification. Refused Out of resources A700-A7FF Upon failure to store data to the archive server, the user will be notified. Error Data set does not match A900-A9FF Same as A7xx. SOP class Error annot understand 000-FFF Same as A7xx. Warning oercion of data B000 Ignored elements Warning Data set does not match B007 Same as A7xx. SOP class Warning Elements discarded B006 Ignored The behavior of the Storage SU AE during communication failure is summarized in Table Table Storage AE ommunication Failure Behavior Ext. Neg. None Exception Association is rejected by SP Association aborted by the SP annot establish TP/IP connection to SP TP/IP connection is reset Timeout Storage AE Behavior The send job is marked as failed. The reason is logged and the job failure is reported to the user via the application. The Storage request will be retried periodically. If the number of retries is exceeded, the send job is marked as failed. The reason is logged and the job failure is reported to the user via the application. The Association is aborted using A-ABORT. The Storage request will be retried periodically. If the number of retries is exceeded, the send job is marked as failed. The reason is logged and the job failure is reported to the user via the application.

21 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 21 of SOP Specific onformance to Storage ommitment SOP lasses N-ATION Storage ommitment Operation Upon the successful completion of storage of a series of images to the archive server, the Storage SU AE will open a separate association with the Storage ommitment SP. The Storage SU AE will consider Storage ommitment failed if no N-EVENT-REPORT is received for a Transaction UID within a configurable time period after receiving a successful N-ATION response (duration of applicability for a Transaction UID). The Storage ommitment Information Attributes are listed in Table The behavior of Storage AE when encountering status codes in an N-ATION response is summarized in the Table 3.2-5: Service Status Table Storage SU AE Behavior to Status Returned from SP Meaning Error ode Storage AE Behavior Success Normal status 0000 Upon a successful commitment response from the storage ommitment server, the Storage SU AE will continue operation. Exams will be marked with storage commitment status = OMMITED. Failure Returned Failure ode 0xXXXX The Storage ommitment request will be retried periodically. The number and period of retries is configurable. If the number of retries is exceeded, the exams will be marked with storage commitment status = FAILED. The behavior of the Storage SU AE during communication failure is summarized in Table Table Storage SU AE ommunication Failure Behavior Exception Association is rejected by SP Association aborted by the SP annot establish TP/IP connection to SP TP/IP connection is reset Timeout Behavior The Storage ommitment request will be retried periodically. The number and period of retries is configurable. If the number of retries is exceeded, the exams will be marked with storage commitment status = FAILED. The Association is aborted using A-ABORT. The Storage ommitment request will be retried periodically. The number and period of retries is configurable. If the number of retries is exceeded, the exams will be marked with storage commitment status = FAILED.

22 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 22 of N-EVENT-REPORT Storage ommitment Operation The Storage SU AE is capable of receiving an N-EVENT-REPORT notification over associations that have successfully negotiated a Presentation ontext for the Storage ommitment Push Model. The behavior of Storage SU AE when encountering Event Types within the N-EVENT-REPORT is summarized in Table Table Storage ommitment N-EVENT-REPORT Behavior Event Type Name Event Type ID Storage AE Behavior Storage ommitment Request Successful 1 Upon a successful commitment response from the storage ommitment server, the Storage SU AE will continue operation. Instances will be marked with storage commitment status = OMMITED. Storage ommitment Request omplete Failures exist 2 The Referenced SOP Instances in the Referenced SOP Sequence are treated the same way as in the success case. The referenced SOP instances in the Failed SOP Sequence will have Storage ommitment requests retried periodically. The number and period of retries is configurable. If the number of retries is exceeded, the instances will be marked with storage commitment status = FAILED. The status codes returned for an N-EVENT-REPORT response are summarized in Table Service Status Table Storage ommitment N-EVENT-REPORT Response Status Further Meaning Status ode Reason Success Success 0000 The storage commitment result has been successfully received Association Acceptance Policy Activity Receive Storage ommitment Response Description and Sequencing of Activities The Storage SU AE will accept associations in order to receive responses to a Storage ommitment Request. Storage SU AE Image Manager 1. Open Association 2. N-EVENT-REPORT (Storage ommitment Response 3. lose Association Figure Sequencing of Activity Receive Storage ommitment Response

23 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 23 of 54 A possible sequence of interactions between the Storage SU AE and an Image Manager (e.g. a device such as a PAS which supports the Storage ommitment SOP lasses as an SP) is illustrated in Figure The Image Manager opens a new association with the Storage SU AE. 2. The Image Manager sends an N-EVENT-REPORT request notifying the Storage SU AE of the status of a previous Storage ommitment Request. The Storage SU AE replies with an N-EVENT- REPORT response confirming receipt. 3. The Image Manager closes the association with the Storage SU AE. The Storage SU AE may reject association attempts as shown in Table The Result, and Reason/Diag columns represent the values returned in the appropriate fields of an ASSOIATE-RJ PDU (see PS 3.8, Section 9.3.4). The contents of the column is abbreviated to save space and the meaning of the abbreviations are: a) 1 DIOM UL service-user b) 2 DIOM UL service-provider (ASE related function) c) 3 DIOM UL service-provider (Presentation related function) 2 rejected transient Table Association Rejection Reasons Result Reason/Diag Explanation c 2 local-limitexceeded 1 rejectedpermanent 1 rejectedpermanent a a 2 applicationcontext-namenot-supported 7 called-aetitle-notrecognized Accepted Presentation ontexts The maximum number of simultaneous associations has been reached. An association request with the same parameters may succeed at a later time. The association request contained an unsupported Application ontext Name. An association request with the same parameters will not succeed at a later time. The association request contained an unrecognized alled AE Title. An association request with the same parameters will not succeed at a later time unless configuration changes are made. This rejection reason normally occurs when the association initiator is incorrectly configured and attempts to address the association acceptor using the wrong AE Title. The Storage SU AE will accept Presentation ontexts as shown in Table Table Acceptable Presentation ontexts for Storage SU AE Presentation ontext Table Abstract Syntax Transfer Syntax Name UID Name List UID List Role Verification Implicit VR Little Endian SP Explicit VR Little Endian Explicit VR Big Endian Storage Implicit VR Little Endian SU ommitment Explicit VR Little Endian Push SOP Explicit VR Big Endian lass Ext. Neg. None None

24 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 24 of 54 The Transfer Syntax preference order is configurable SOP Specific onformance for Storage ommitment SOP lass N-EVENT-REPORT Storage ommitment Notification The behavior of the Storage SU AE when receiving Event Types within the N-EVENT-REPORT is summarized in Table The reasons for returning specific status codes in an N-EVENT-REPORT response are summarized in Table SOP Specific onformance for Verification SOP lass The Storage SU AE provides standard conformance to the Verification SOP lass as an SP. If the - EHO request was successfully received, a 0000 (Success) status code will be returned in the -EHO response Workflow Management Application Entity Specification SOP lasses The Workflow Management AE provides conformance to the following DIOM SOP lasses: Table SOP lasses for Workflow Management Application Entity SOP lass Name SOP lass UID SU SP Verification Yes No Modality Worklist Information Model - FIND Yes No Modality Performed Procedure Step Yes No Association Policies General The DIOM standard application context name for DIOM 3.0 is always proposed: Application ontext Name: Maximum PDU size offered: 32,768 bytes Maximum PDU size accepted: 65,536 bytes Number of Associations Maximum number of simultaneous associations: Asynchronous Nature The Workflow Management AE will not use asynchronous operations window negotiation Implementation Identifying Information Implementation lass UID: dddddddd Implementation Version Name: NAI xxxx Note: is registered by NAI Tech Products with ANSI. dddddddd and xxxx are subject to change with new software releases.

25 MDR (Medical Digital Recorder ) Video and Video RP DIOM onformance Statement 25 of Association Initiation Policy Activity - onnectivity Verification Description and Sequencing of Activities The Workflow Management AE may initiate an Association for the purpose of verifying a DIOM connection Proposed Presentation ontext Table The Workflow Management AE will propose the Presentation ontexts as shown in Table Table Proposed Presentation ontext for onnectivity Verification Presentation ontext Table Abstract Syntax Transfer Syntax Name UID Name List UID List Role Verification Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian SU Extended Negotiation None SOP Specific onformance for onnectivity Verification The Workflow Management AE provides standard conformance to the DIOM Verification Service lass as an SU Activity - Worklist Update Description and Sequencing of Activities The request for a Worklist Update is initiated by user interaction, or automatically at specific time intervals, configurable by the user. The user can configure data for use as search criteria. When the query is started on user request or automated query the configured data will be inserted as matching keys into the query. Upon initiation of the request, the MDR Video will build an Identifier for the -FIND request, and will initiate an Association to send the request according to the Modality Worklist Information Model. The Workflow Management AE will then wait for Worklist responses. After retrieval of all responses, the Workflow Management AE will access the local database to add or update patient demographic data, as needed. The association is closed at completion of the query.