General Electric MUSE v9 DICOM Gateway Pro Conformance Statement_SM_2059568-023_B MUSE v9.0 MUSETM DICOM Gateway Pro Conformance Statement for DICOM v3.0

Download

Page 1

GE Healthcare

Technical Publications

Direction 2059568-023 Revision B

MUSE MUSE

v9.0 \

DICOM Gateway Pro

Conformance Stat emen t for DICOM v3.0

Page 2

GE Healthcare

Do not duplicate

THIS PAGE LEFT INTENTIONALLY BLANK.

Page 3

GE Healthcare

CONFORMANCE STATEMENT OVERVIEW

Table 0.1 provides an overview of the network services supported by MUSE

Table 0.1 – NETWORK SERVICES

SOP Classes User of Service

(SCU)

Transfer

12-lead ECG Waveform Storage Yes Yes General ECG Waveform Storage Yes No Encapsulated PDF Storage Yes Yes

Workflow Management

Storage Commitment Push Model SOP Class Yes Yes Modality Worklist Information Model – FIND SOP Class Yes No

Provider of

Service (SCP)

Page 4

GE Healthcare

TABLE OF CONTENTS

1. INTRODUCTION ............................................................................................................... 9

1.1 Overview ..................................................................................................................................................................... 9

1.2 Overall DICOM Conformance Statement Document Structure .......................................................................... 11

1.3 Intended Audience ................................................................................................................................................... 12

1.4 Scope and Field of Application ............................................................................................................................... 12

1.5 Important Remarks ................................................................................................................................................. 13

1.6 References ................................................................................................................................................................. 14

1.7 Definitions ................................................................................................................................................................. 14

1.8 Symbols and Abbreviations ..................................................................................................................................... 16

2. NETWORK CONFORMANCE STATEMENT .................................................................. 17

2.1 Introduction .............................................................................................................................................................. 17

2.2 Implementation Model............................................................................................................................................. 18

2.2.1 Application Data Flow Diagram ........................................................................................................................ 18

2.2.1.1 Application Data Flow Diagram – Storage SCU AE ..................................................................................... 18

2.2.1.2 Application Data Flow Diagram - Storage SCP AE ....................................................................................... 19

2.2.1.3 Application Data Flow Diagram - Modality Worklist SCU AE ..................................................................... 20

2.2.2 Functional Definition of AE's............................................................................................................................. 22

2.2.2.1 Functional Definition – MUSE DICOM Storage Service (SCU) AE ............................................................. 22

2.2.2.2 Functional Definition – MUSE DICOM Storage Service (SCP) AE ............................................................. 22

2.2.2.3 Functional Definition - Modality Worklist SCU AE ...................................................................................... 23

2.2.3 Sequencing of Real-World Activities ................................................................................................................. 24

2.2.3.1 Sequencing – Storage SCU AE ...................................................................................................................... 24

2.2.3.1.1 Send Storage Commitment Request......................................................................................................... 24

2.2.3.2 Sequencing - Storage SCP AE ....................................................................................................................... 25

2.2.3.2.1 Send Storage Commitment Response ...................................................................................................... 25

2.2.3.3 Sequencing - Modality Wor klist SCU AE ..................................................................................................... 26

2.3 AE Specifications ..................................................................................................................................................... 27

2.3.1 AE Specification - All Application Entities ....................................................................................................... 27

2.3.1.1 Maximum Length of Protocol Data Unit ........................................................................................................ 28

2.3.1.2 Association Policies ....................................................................................................................................... 28

2.3.1.2.1 General .................................................................................................................................................... 28

2.3.1.2.2 Asynchronous Nature .............................................................................................................................. 28

Page 5

GE Healthcare

2.3.1.2.3 Implementation Identifying Information .................................................................................................. 28

2.3.1.2.4 Transfer Syntaxes Supported ................................................................................................................... 29

2.3.1.3 Timers ............................................................................................................................................................ 29

2.3.1.3.1 Association Timers .................................................................................................................................. 29

2.3.1.3.2 Operation Inactivity Timer ...................................................................................................................... 29

2.3.2 AE Specification – MUSE DICOM Storage Service (SCU) .............................................................................. 29

2.3.2.1 Association Establishment Policies ................................................................................................................ 30

2.3.2.1.1 General .................................................................................................................................................... 30

2.3.2.1.2 Number of Associations........................................................................................................................... 30

2.3.2.1.3 Asynchronous Nature .............................................................................................................................. 31

2.3.2.1.4 Implementation Identifying Information .................................................................................................. 31

2.3.2.2 Association Initiation Policy .......................................................................................................................... 31

2.3.2.2.1 Real-World Activity - Send SOP Instance(s) to Remote AE ................................................................... 31

2.3.2.3 Association Acceptance Policies .................................................................................................................... 35

2.3.3 AE Specification – MUSE DICOM Storage Service (SCP) .............................................................................. 35

2.3.3.1 Association Establishment Policies ................................................................................................................ 35

2.3.3.1.1 General .................................................................................................................................................... 36

2.3.3.1.2 Number of Associations........................................................................................................................... 36

2.3.3.1.3 Asynchronous Nature .............................................................................................................................. 36

2.3.3.1.4 Implementation Identifying Information .................................................................................................. 36

2.3.3.2 Association Acceptance Policy ...................................................................................................................... 36

2.3.3.2.1 Real-World Activity - Receive SOP Instance from Remote AE .............................................................. 36

2.3.3.3 Supported Uses of SOP Instances .................................................................................................................. 42

2.3.3.3.1 Data Storage ............................................................................................................................................ 42

2.3.3.3.2 Information routing and distribution ........................................................................................................ 42

2.3.3.3.3 Data Display ............................................................................................................................................ 42

2.3.3.3.4 Printing data............................................................................................................................................. 42

2.3.4 AE Specification - DICOM Storage Commitment Service – Pus h Model (SCU) ............................................. 42

2.3.4.1 Association Establishment Policies ................................................................................................................ 43

2.3.4.1.1 General .................................................................................................................................................... 43

2.3.4.1.2 Asynchronous Nature .............................................................................................................................. 43

2.3.4.1.3 Implementation Identifying Information .................................................................................................. 43

2.3.4.2 Association Acceptance Policies .................................................................................................................... 43

2.3.4.2.1 Real-World Activity - Receive storage commitment response from Remote AE .................................... 44

2.3.4.3 Association Initiation Policy .......................................................................................................................... 46

2.3.4.3.1 Real-World Activity - Send Storage Commitment Request to the Remote AE ....................................... 46

2.3.5 AE Specification - DICOM Storage Commitment Service – Pus h Model (SCP ) ............................................. 48

2.3.5.1 Association Establishment Policies ................................................................................................................ 48

2.3.5.1.1 General .................................................................................................................................................... 48

2.3.5.1.2 Number of Associations........................................................................................................................... 48

2.3.5.1.3 Asynchronous Nature .............................................................................................................................. 49

2.3.5.1.4 Implementation Identifying Information .................................................................................................. 49

2.3.5.2 Association Initiation Policy .......................................................................................................................... 49

2.3.5.2.1 Real-World Activity - Send Storage Commitment response to remote AE ............................................. 49

2.3.5.3 Association Initiation Policy .......................................................................................................................... 51

2.3.5.3.1 Real-World Activity - Receive Storage Commitment request from remote AE ...................................... 51

2.3.6 AE Specification - MUSE DICOM Modality Worklist Find (SCU) ................................................................. 53

2.3.6.1 Association Establishment Policies ................................................................................................................ 54

2.3.6.1.1 General .................................................................................................................................................... 54

2.3.6.1.2 Number of Associations........................................................................................................................... 54

2.3.6.1.3 Asynchronous Nature .............................................................................................................................. 54

2.3.6.1.4 Implementation Identifying Information .................................................................................................. 54

Page 6

GE Healthcare

2.3.6.2 Association Initiation Policy .......................................................................................................................... 54

2.3.6.2.1 Real-World Activity - Query Modality Worklist items from a remote AE .............................................. 54

2.4 Communication Profiles .......................................................................................................................................... 57

2.4.1 Supported Communication Stacks ..................................................................................................................... 57

2.4.2 Physical Media Support ..................................................................................................................................... 57

2.5 Extensions / Specializations/ Privatizations ........................................................................................................... 57

2.5.1 Standard Extended / Specialized / Private SOP Classes .................................................................................... 57

2.5.2 Private Transfer Syntaxes .................................................................................................................................. 57

2.6 Configuration ........................................................................................................................................................... 57

2.6.1 AE Title/Presentation Address Mapping ............................................................................................................ 57

2.6.2 Configurable Parameters .................................................................................................................................... 58

2.6.2.1 Local AE Title ................................................................................................................................................ 58

2.6.2.2 Remote AE Title ............................................................................................................................................ 58

2.6.3 Maximum PDU Size Accepted .......................................................................................................................... 59

2.6.4 MUSE DICOM Time-out .................................................................................................................................. 59

2.6.4.1.1 Remote AE Title / Presentation Address Mapping .................................................................................. 59

2.7 Support of Extended Charac ter Sets ...................................................................................................................... 59

2.8 Codes and Controlled Terminology........................................................................................................................ 59

2.9 Security Profiles ....................................................................................................................................................... 59

Page 7

GE Healthcare

Table of Tables

Table 1 ....................................................................................................................................................................................... 29

Table 2: SOP Classes Supported by Storage SCU AE .............................................................................................................. 30

Table 3: MUSE Test type to DI COM IOD Translation rules .................................................................................................. 32

Table 4: Proposed Presentation Contexts by Storage SCU AE ................................................................................................. 33

Table 5: Command Response Status Handling in Storage SCU AE ......................................................................................... 34

Table 6: Command Communication Failure Behavior of Storage SC AE ................................................................................ 35

Table 7: SOP Classes Supported by Storage SCP AE .............................................................................................................. 35

Table 8: Acceptable Presentation Context for Storage SCP AE ............................................................................................... 38

Table 9: Status Codes Returned in C-STORE-RSP by Storage SCP AE .................................................................................. 39

Table 10: Data Elements that may be truncated when stored in MUSE Database .................................................................... 40

Table 11: Data Elements that might be impacted by Coercion of SOP Instances ..................................................................... 41

Table 12: SOP Class supported for Storage Commitment Request in MUSE DICOM Storage SCP AE ................................. 43

Table 13: Accepted Presentation Context for Storage Commitment by Storage SCU AE ........................................................ 44

Table 14: Proposed Presentation Context for Storage Commitment Requests by Storage SCU AE......................................... 47

Table 15: Data Elements Sent in Storage Commitment Request by Storage SCU AE .............................................................. 47

Table 16: Date Elements Unused in Storage Commitment Request by Storage SCU AE ........................................................ 48

Table 17: T ABLE 11: SOP CLASSES SUPPORTED BY STORAGE Commitment SCP AE............................................... 48

Table 18: Proposed presentation context for Storage Commitment report ............................................................................... 50

Table 19: Data elements included in successful Storage Commitment report ........................................................................... 50

Table 20: Data Elements included in failed Storage Commitment response by Storage SCP AE ............................................ 51

Table 21: Data Elements Supported in Storage Commitment Request by Storage SCP AE ..................................................... 52

Table 22: Data Elements in Storage Commitment Request Ignored by Storage SCP AE ......................................................... 53

Table 23: SOP Class for Modality Worklist SCU AE .............................................................................................................. 54

Table 24: Proposed Presentation Context by Modality Worklist SCU AE ............................................................................... 55

Page 8

GE Healthcare

Table 25: Fields used for filtering Moda lity worklist ............................................................................................................... 55

Table 26: Modality Worklist Response Key Mapping Information .......................................................................................... 56

Page 9

GE Healthcare

1. INTRODUCTION

1.1 OVERVIEW

This DI COM Conformance Statement describes in detail the DICOM support provided by MUSE v9.0 and MUSE DICOM Gateway Pro. The difference between MUSE v9.0 and MUSE DICOM Gateway Pro with respect to DICOM support is that MUSE DICOM Gateway Pro does not support the Storage SCP and Storage Commitment SCP. For sections that are not applicable to MUSE DICOM Gateway Pro, a note is added at the beginning of the section mentioning the same.

This DICOM Conformance Statement is divided into sections as described below:

Section 1 (Introduction) describes the overall structure, intent, and references for this

Conformance Statement.

Section 2 (Network Conformance Statement) specifies compliance of MUSE to DICOM

v3.0 Standards requirements for network communication for all SOP classes it supports. This part generally follows the DICOM Standard Conformance Statement as specified in the DICOM Standard V3.0, Part 2. General network operations are d escribed in this section. In the places that individual real-work activities should be described, references to the following sections are made, instead of including all SOP classes in this part.

Section 2.3 (Application Entity Specifications) provides a set of Application Entity

Specifications. There is one specification for each Application Entity MUSE supports. Each individual AE Specification has a subsection. There are as many of these subsections as there are different AE's in the implementation.

Section 2.3.1 (AE Specification – All Application Entities) specifies a set of common

compliance elements of all MUSE DICOM Application Entities to DICOM v3.0 Standards requirements for all SOP Classes.

Section 2.3.2 (AE Specification - DICOM Storage Service SCU) specifies compliance of

MUSE SOP Instance send functions to DICOM v3.0 Standards requirements for Storage SOP Classes.

Section 2.3.3 (AE Specification - DICOM Storage Service SCP) specifies compliance of

MUSE SOP Instance receive functions to DICOM v3.0 Standards requirements for Storage SOP Classes.

Section 2.3.4 (AE Specification - DICOM Storage Commitment – Push Model SCU)

specifies the compliance of the MUSE SOP Instance Storage Commitment request functions to DICOM v3.0 Standards requirements for Storage Commitment – Push Model SOP Classes.

Page 10

GE Healthcare

Section 2.3.5 (AE Specification - DICOM Storage Commitment – Push Model SCP)

specifies the compliance of the MUSE SOP Instance Storage Commitment response functions to DICOM v3.0 Standards requirements for Storage Commitment – Push Model SO P Classes.

Section 2.3.6 (AE Specification - DICOM Modality Worklist – Find SCU) specifies the

compliance of MUSE Modality Worklist – Find q uer y functio ns t o D I COM v3. 0 Standards requirements for querying for Modality Worklist items.

Page 11

GE Healthcare

1.2 OVERALL DICOM CONFORMANCE STATEMENT DOCUMENT STRUCTURE

The Documentation Structure of the GE Healthcare Conformance Statements and their relationship to the DICOM v3.0 Conformance Statements is shown in the illustration below.

IGURE 1-1: DICOM CONFORMANCE STATEMENT DOCUMENT ORGANIZATION

The documenta tion structure depicted in the illustration above shows the overall documentation structure for all GE ID/Net v3.0 Conformance Statements. This document specifies the DICOM v3.0 implementation supported by the GE Healthcare’s MUSE Cardiology Information System.

It is entitled:

MUSE Version 9.0\ Conformanc e Statement for DICOM V3.0

Direction 2059568-023

MUSE DICOM Gatewa y Pro

Page 12

GE Healthcare

This DICOM Conformance Statement documents the DICOM Conformance Statement and Technical Specification required to interoperate with the GE Healthcare network interface.

The GE Healthcare Conformance Statement, contained in this document, also specifies the Lower Layer communications which it supports (e.g., TCP/IP). However, the Technical Specifications are defined in the DICOM Part 8 standard.

For more information regarding DICOM, copies of the standard may b e obtained on the

. Comments on the standard may be addressed to:

1.3 INTENDED AUDIENCE

Internet at http://medical.nema.org DICOM Secretariat

NEMA 1300 N. 17 Rosslyn, VA 22209 USA Phone: +1.703.841.3200

Street, Suite 1752

The reader of this document is concerned with software design and/or system integration issues. It is assumed that the reader of this document is familiar with the DICOM v3.0 Standard a nd with the terminology and c o ncepts which are used in that standard.

If readers are unfamiliar with DICOM v3.0 terminology they should first refer to the document listed below and read the DICOM v3.0 Standard itself, prior to reading this DICOM Conformance Statement document.

Introduction to the Integrated DICOM/Network v3.0 (ID/Net v3.0) Conformance Statements Direction: 2118780

1.4 SCOPE AND FIELD OF APPLICATION

It is the intent of this document, in conjunction with the Introduction to the Integrated DICOM/Network v3.0 (ID/Net v3.0) Conformance Statement, Direction: 2118780, to

provide an unambiguous specification for GE ID/Net v3.0 implementations. This specification, called a Conformance Statement, includes a DICOM v3.0 Conformance Statement and is necessary to ensure proper processing and interpretation of GE Healthcare data exchanged using DICOM v3.0. The GE ID/Net v3.0 Conformance Statements are available to the public.

The reader of this DICOM Conformance Statement should be aware that different GE Healthcare devices are capable of using different Information Object Definitions. For example, a GE Healthcare CT Scanner may send images using the CT Information Object, MR Information Object, Secondary Capture Object, etc.

Page 13

GE Healthcare

Included in this DICOM Conformance Statement are the Module Definitions which define all data elements used by the GE ID/Net v3.0 implementation. If the user encounters unspecified private data elements while parsing a GE Dataset, the user is well advised to ignore those data elements (per the DICOM v3.0 standard). Unspecified private data element information is subject to change without notice. If, however, the device is acting as a "full fidelity storage device", it should retain and retransmit all of the private data elements which are sent by GE Healthcare devices.

1.5 IMPORTANT REMARKS

The use of these DICOM Conformance Statements, in conjunction with the DICOM Standards, is intended to facilitate co mmunication with GE imaging equipment. However,

by itself, it is not sufficient to ensure that interoperation will be successful. The user (or user's agent) needs to proceed with caution and address at least four issues:

• Integration - The integration of any device into an overall system of interconnected

devices goes beyond the scope of standards (DICOM v3.0), and of this introduction and associated DICOM Conformance Statements when interoperability with non-GE equipment is desired. The responsibility to analyze the applications’ requirements and to design a solution that integrates GE imaging equipment with non–GE systems is the user's responsibility and should not be underestimated. The user is strongly advised to ensure that such an integration analysis is correctly performed.

• Validation - Testing the complete range of possible interactions between any GE

device and non–GE devices, before the connection is declared operational, should not be overlooked. Therefore, the user should ensure that any non–GE provider accepts full responsibility for all validation required for their connection with GE devices. This includes the accuracy of the image data once it has crossed the interface between the GE imaging equipment and t he non–GE device, as well as the stability of the image data for the intended applications.

Such a validation is required before any clinical use (diagnosis and/or treatment) is performed. It applies when images acquired on GE imaging equipment are processed/displayed on a non-GE device, as well as when images acquired on nonGE equipment is processed/displayed on a GE console or workstation.

• Future Evolution - GE understand s that the DICOM Standard will evolve to meet

the user's growing req uirements. GE is actively invol ved in the development of the DICOM Standard. DICOM will incorporate new features and technologies and GE may follow the evolution of the standard. The GE Healthcare protocol is based on DICOM as specified in each DICOM Conformance Statement. Evolution of the standard may require changes to devices which have implemented DICOM. In

addition, GE reserves the rig ht to disco ntinue o r make changes to the support of communications features (on its products) described by these DICOM Conformance Statements. The user should ensure that any non–GE provider, which

connects with GE devices, also plans for the future evolution of the DICOM Standard. Failure to do so will likely result in the loss of function and/or connectivity as the DICOM Standard changes and GE products are enhanced to support these changes.

Page 14

GE Healthcare

• Interaction - It is the sole responsibility of the non–GE provider to ensure that

communication with the interfaced equipment does not cause degradation of GE imaging equipment performance and/or function.

1.6 REFERENCES

NEMA PS 3 Digital Imaging and Communications in Medicine (DICOM)

Standard, available free at http://medical.nema.org/

1.7 DEFINITIONS

Informal definitions are provided for the following terms used in this Conformance Statement. The DICOM Standard is the authoritative source for formal definitions of these terms.

Abstract Syntax – the information agreed to be exchanged between applications, generally equivalent to a Service/Object Pair (SOP) Class. Examples: Ver ification SOP Class, Modality Worklist Information Model Find SOP Class, Computed Radiography Image Storage SOP Class.

Application Entity (AE) – an end point of a DICOM infor mation exchange, including the DICOM network o r 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 e xternally known name of an Applica tion Entity, used to identify a DICOM application to other DI COM a pplications 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 encoding exchanged on removable media (e.g., CDs)

Page 15

GE Healthcare

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, Patie nt Birth Date, and Patient Sex.

Negotiation – fir st pha se of Association establishment that allows Application En tities 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 E ntity that uses a DICOM network service; typically, a client. Examples: imaging modality (image storage SCU, and modality worklist SCU), imaging workstation (image query/retrieve SCU)

Service/Object Pair (SOP) Class – the specification of the network or media transfer (service) of a particular type of data (object); the fundamental unit of DICOM interoperability specification. Examples: Ultrasound Image Storage Service, Basic Grayscale Print Management.

Service/Object Pair (SOP) Instance – an information object; a specific occurrence of information exchanged in a SOP Class. Examples: a specific x-ray image.

Tag – a 32-bit identifier for a data element, represented as a pair of four digit hexadecimal numbers, the “group” and the “element”. If the “group” number is odd, the tag is for a private (manufacturer-specific) data element. Examples: (0010,0020) [Patient ID], (07FE,0010) [Pixel Data], (0019,0210) [private data element]

Transfer Syntax – the encoding used for exchange of DICOM information objects and messages. Examples: JPEG compressed (images), little endian explicit value representation.

Unique Identifier (UID) – a globally unique “dotted decimal” string that identifies a specific object or a class of objects; an ISO-8824 Object Identifier. Examples: Study Instance UID, SOP Class UID, SOP Instance UID.

Page 16

GE Healthcare

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.

1.8 SYMBOLS AND ABBREVIATIONS

A list of symbols and abbreviations which is applicable to all GE Healthcare Conformance Statements is included in the Introduction to the Integrated DICOM/Network v3.0 (ID/Net v3.0) Conformance Statement, Direction: 2118780.

Below is a list of abbreviations used in this document over and above the ones in the referred document.

CPOE Computerized Physician Order Entry

CSI Client Server Interface

ECG Electrocardiogram

EMR Electronic Medical Records

Hilltop Internal proprietary binary data format for ECG Studies in MUSE

HIS Hospital Information System

IS Information Syste ms

MAC Microprocessor Augmented Cardiograph

MUSE Marquette Universal System for Electrocardiography

PDF Portable Document Format

DICOM Digital Imaging and Communications in Medicine

AE Application Entity

SCP Service Class Provider

SCU Service Class User

MWL Modality Work List

Page 17

GE Healthcare

2. NETWORK CONFORMANCE STATEMENT

2.1 INTRODUCTION

This section of the DICOM Conformance Statement specifies the MUSE v9.0 and MUSE DICOM Gateway Pro compliance to DICOM requirements for networking features.

• Send DICOM SOP Instances to remote DICOM devices. The following SOP Classes are supported:

o 12-Lead Electrocardiogram (for resting ECGs of 10 seconds or less). o Encapsulated PDF SOP Instances (for resting ECGs, Exercise and Ambulatory

ECGs).

• As a part of the Send activity, MUSE can optionally request Storage Commitment for the SOP Instances transmitted from the remote Application Entity.

• Receive DICOM SOP Instances from remo te DICOM devices into MUSE for storage. The following DICOM SOP Instances can be received by MUSE

o 12-Lead Electrocardiogram SOP Instances. o General Electrocardiogram SOP Instances. o Encapsulated PDF SOP Instances.

• Respond to Storage Commitment requests for the SOP Instances raised by remote Application Entities who have transmitted such SOP Instances.

Note: Receive D ICOM SOP Instances and St o r age Commitm ent requests for SOP Insta nces are not

supported by MUSE DICOM Gateway Pro application.

• Listen to DICOM Modality Worklist provider, rec e ive, convert to GE format and distribute the Worklist items to GE MAC Electrocardiograph devices.

• Respond to DICOM echo requests from remote Application Entities.

• Request verification from other remote Application Entities.

The MUSE system creates a number of DICOM Application Entities (AEs) to support these services. Each such DICOM Application Entity will be dedicated to a particular type of the DICOM service, as explained in the rest of the document.

Note: In this document, we use the term “DICOM Storage SOP Instance” or “SOP Instance” in places

where the term “Image” is usually used. A SOP Instance generally refers to a DICOM v3.0 Standards Composite IOD, which can be an image or non-image dataset. In most cases, the SOP class to which an instance is associated determines the data type of the instance. For details, the reader is referred to DICOM Standard parts PS 3.3 and 3.4.

Page 18

GE Healthcare

In this document, the term “MUSE” refers to the “MUSE DICOM interface,” a

collection of all of its DICOM Application Entities, their common properties and behaviors. Please note that these services are selectively installed based on customer requirements and not all services will be available at every installation. In general, the MUSE DICOM interface runs as a subsystem comprised of a set of processes installed on the same or different servers, working in tandem with the MUSE.

The DICOM interfaces typically start automatically when the server on which they are installed is booted.

2.2 IMPLEMENTATION MODEL

MUSE provides a number of DICOM Standard services with separate DICOM Application Entities (AEs):

• SOP Instance Send and Storage Commitment request Application Entity (Storage

SCU AE)

• SOP Instance Receive/Store and Storage Commitment response App lic a tion Entity

(Storage SCP AE)

• Modality Worklist request Application Entity (Modality Worklist SCU AE)

2.2.1 Application Data Flow Diagram

The network application model for the MUSE v9.0 is shown in the following illustrations:

2.2.1.1 Application Data Flow Diagram – Storage SCU AE

The Storage SCU AE implements the SCU role for the DICOM Storage SOP Classes and transmits SOP Instances to a remote AE. It optionally makes a DICOM Storage Commitment request from the remote AE, if configured and if the remote AE supports Storage Commitment.

Page 19

GE Healthcare

IGURE 2-1: APPLICATION DATA FLOW DIAGRAM FOR STORAGE SCU AE

2.2.1.2 Application Data Flow Diagram - Storage SCP AE

The Storage SCP AE implements both the SCP role for the DICOM Storage SOP Classes and the SCP role for the DICOM Storage Commitment SOP Class. The SCP role of the DICOM Storage SOP class is responsible for receiving DICOM SOP Instances from a remote AE. The SCP role of the DICOM Storage Commitment SOP class responds to Storage Commitment requests made by a remote AE.

Page 20

GE Healthcare

IGURE 2-2: APPLICATION DATA FLOW DIAGRAM FOR STORAGE SCP AE

2.2.1.3 Application Data Flow Diagram - Modality Worklist SCU AE

The Modality Worklist SCU AE implements DICOM Modality Worklist SOP Classes for receiving Mod ality Worklist items from a remote AE and distributes the worklist items to GE MAC Electrocardiograph devices in the network upon request.

The Modality Worklist SCU AE periodically queries a remote Modality Worklist SCP AE for worklist items. Upon receiving the responses from the remote AE, it maps the returned items to an internal MUSE database and uses proprietary CSI protocol to support the Order and Patient demographic queries raised by GE Electrocardiograph devices.

Note: MUSE supports an HL7 interface for ADT and Orders. Modality Worklist SCU is normally not enabled in MUSE by default and is not required when the HL7 ADT/Order interface is

Page 21

GE Healthcare

in effect. This SCU is provided only in alternate environments where such an HL7 interface is n ot available or feasible, and instead the institutio n can provide a Modality Worklist feed to MUSE. This is true only for GE MAC Electrocardiograph devices, since th ese devices d o no t h ave a bu il t in Modality Worklist SCU.

IGURE 2-3: APPLICATION DATA FLOW DIAGRAM FOR MODALITY WORKLIST SCU AE

Page 22

GE Healthcare

2.2.2 Functional Definition of AE's

The DICOM Application Entities of MUSE initiate or rec eive the DICOM asso ciations to support a number of application functions for the MUSE system.

2.2.2.1 Functional Definitio n – MUSE DICOM Storage Service (SCU) AE

The MUSE DICOM Storage Service (SCU) AE supports the following application-level function:

Transmission related:

• Transfer the selected test(s) from MUSE to a remote AE as DICOM SOP Instances.

Storage Commitment related:

• If all the intended SOP Instances are transferred without failures, the following steps will be executed.

o Send Storage Commitment request for the SOP Instances that were successfully

transmitted as above.

o Receive the Storage Commitment response from the Storage Commitment

Provider on the same association or on a different association.

 If the Storage Commitment response indicates “Success”, mark the

transmission request to a “Success”. The status is reflected in the MUSE transmission/routing logs.

 If the Storage Commitment response indicates “Failure” or “Unknown,”

mark the transmission request as “Failure” or “Unknown”.

• If there are any failures in transfer, the tra nsmission request will be marked as

"Failed” and the Storage Commitment request will not be sent.

o If configured for retry, the SOP Instances would be retried on a separate

association and a new Storage Commitment request would be generated if the retry succeeds.

Note: Due to the data coercion, the SOP Instan ces sent to a r emote AE may be different from

the originally received SO P Instances in certain d ata elements. See corrections in MUSE.

2.2.2.2 Functional Definitio n – MUSE DICOM Storage Service (SCP) AE

Note: MUSE DICOM Storage Service (SCP) AE is not applicable to MUSE DICOM Gateway Pro

The MUSE DICOM Storage Service (SCP) AE supp orts the following application-level functions:

Storage related:

• Receive SOP Instances from a remote DICOM AE.

2.3.3.2.1.7 for possible data

Page 23

GE Healthcare

• Profile each received instance to an Ordered Scheduled Study in MUSE by matching the

Patient / Study information in the instance’s dataset to the information in the database.

• If no match is found, create a new (unordered) Study by directly using the Patient / Study

information in the received dataset and relate the SOP Instance to the created study.

Note: When relating a SOP Instance to an Ordered study, the Storage SCP AE may alter the values of

some data elements using the values from the counterpart data fields of the matched study in the MUSE database. In addition, the SOP Instances may also be changed by the Patient Study update information received from EMR/HIS or entered by the MUSE Editor operator. MUSE does not create a new SOP Instance for these data changes. A list of the data elements that may undergo data coercion are given in 2.3.3.2.1.7. Data coercion is performed for data correct ion purposes.

• Store the Patient, Study, Series, and SOP Instance relationship permanently in the MUSE.

• Store the SOP Instances in the MUSE for use in MUSE Editor and for long-term storage.

Note: MUSE will properly save all SOP Instances successfully received via the Storage SCP AE.

However, MUSE cannot guarantee that all received SOP Instances can be properly displayed and printed.

2.3.3.3 lists the detailed application level functions that MUSE is able to support for the successfully

Section received SOP Instances.

Storage Commitment related:

• Receive a DICOM Storage Commitment request from a remote AE.

• Create a request entry in the MUSE Storage Commitment Queue. The request is identified

by the Transaction UID in the received request and associated with a timer of a configurable time-out value.

• Poll the Storage Commitment Queue for a pending request which is either confirmed by

normalization process or timed out.

• Send a Storage Commitment response to remote AE.

Note: The Storage SCP AE supports a Storage Commitment request for the SOP Instances unknown to the MUSE at the moment. The Storage SCP AE assumes that th ese S OP In stan ces will be received at a later time.

Verification related:

• Respond to a DICOM Verification (Echo) request from a remote AE.

2.2.2.3 Functional Definitio n - Modality Worklist SCU AE

The Modality Worklist SCU AE supports the following application-level function:

Modality Worklist request:

• MUSE will periodically query the remote Modality Worklist SCP AE for the worklist

items pertinent to its environment. The query attributes used by MUSE are configurable.

Page 24

GE Healthcare

• Typically MUSE will query items marked for “ECG” modality that pertain to the

locations managed by the MUSE server initiating the query.

Modality Worklist receipt and process:

• Upon receiving the worklist items in the response from the remote Modality Worklist

SCP AE, MUSE will parse the items and translate them into Orders and/or Patient demographics and store them in its database.

2.2.3 Sequencing of Real-Wo r ld Ac tivities

2.2.3.1 Sequencing – Storage SCU AE

Following real-world activities will cause the Storage SCU AE to initiate a DICOM association to a remote AE to route the MUSE tests.

1. MUSE allows a user to select and route DICOM or non-DICOM tests stored internally

to remote Application Entities in one or more of the following ways:

• A MUSE Administrator user has set up routing rules to route the tests to other IS

entities based on various stages of the workflow automatically.

• A MUSE user, who has the appropriate privilege, queries the MUSE Cardiology

Information System for tests meeting selection criteria in the MUSE Editor application and routes the result set to a remote AE.

• A MUSE user, who has the appropriate privilege, selects a desired set of tests

manually and routes it to a remote AE for further research.

The exact trigger mechanism and t he configuration method for these triggers are beyond the scope of this document.

Under these c onditions:

1. In response to this action, MUSE will enter the requests in a routing queue and process

the referenced studies (and hence the SOP Instances) to be transmitted to the remote AE.

2. MUSE will process these requests p er internal order of priority and initiate a DICOM

transmission to the remote AE identified in the request.

The ECG tests will be transmitted as one of the Information Object types per the table in

Section 3.2.1

, based on test types.

2.2.3.1.1 Send Storage Commitment Request

MUSE implements an optional Storage Commitment request/response during the realworld activity where tests in MUSE are transmitted to a remote AE for storage.

Page 25

GE Healthcare

If the remote AE supports Storage Commitment, the MUSE application can be configured to request a Storage Commitment response from the remote Stora ge SCP AE to build in additional reliability.

Other than configur ing the necessary remote AE information in MUSE, which only needs to be done once, no additional real-world activity is needed to request Storage Commitment. MUSE automatically sends Storage Commitment requests to the remote AE upon successful transmission of SOP Instances if configur ed.

2.2.3.2 Sequencing - Storage SCP AE

Note: MUSE DICOM Storage Service (SCP) AE is not applicable to MUSE DICOM Gateway Pro.

A physician orders an ECG test for the patient at their CPOE/EMR/HIS applic ation. At the time the study is ordered, the third party information system sends the study order and patient information to MUSE, which creates an ordered study and then expects to receive SOP Instances associated with this study.

The following real-world activities are associated with the receiving Storage SOP Instance operations:

1. Either the modality is able to query the Modality Worklist from a DICOM Modality

Worklist Provider or a tec hnologist enters the patient / study information manually in the electrocardiograph. The te chnologist then acquires the ECG from the patient.

2. The electrocardiograph acquires the ECG as a DICOM Storage SOP Instance and

sends these to the Storage SCP Application Entity of MUSE.

3. The Storage SCP Application Entity matches the DICOM objects received from the

electrocardiograph to an ordered study in the database.

After acquiring one or more ECGs in a device that is capable of sending ECGs using the DICOM protocol, the electrocardiograph operator shall use the vendor provided UI to initiate a single or batch transmission of ECGs to MUSE Storage SCP AE.

This would ca use t he electrocardiograph’s Storage SCU AE to initiate an association with the MUSE Storage SCP AE and transmit the ECG(s). For this action to be successful, the MUSE Storage SCP AE information needs to be configured in the vendor’s electrocardiograph with the help of relevant vendor manuals.

2.2.3.2.1 Send Storage Commitment Response

If the electrocardiograph that transmitted the ECG SOP Instances is capable of requesting a Storage Commitment request (please refer to vendor documentation on how to configure this in your respective device), the device can request the Commitment either

Page 26

GE Healthcare

on the same association in which it sent the SOP Instances or it can chose to initiate a dedicated association for this purpose.

No local real-world activity is required for the Storage SCP AE to respond to incoming DICOM associations for Storage Commitment requests. The Storage SCP AE is always listening for an incoming association and will automatically respond to requests.

Upon receiving a Storage Commitment request, the Storage SCP AE will start the following real-world activities:

1. The request is entered in the Storage Commitment request queue in the MUSE

database.

2. A timer for a configured time-out value associated with the request is started.

3. The Storage SCP AE periodically polls all outstanding Stora ge Commitment requests

and sends Storage Commitment responses back to the remote AE under the following conditions:

• All outstanding commitment requests for SOP Instances queued have been

successfully “Normalized” into the MUSE database.

• The pre-configured time-out has expired, but not all SOP Instances requested

have been successfully “Normalized.”

2.2.3.3 Sequencing - Modality Worklist SCU AE

The Modality Worklist SCU AE in MUSE is provided for a special purpose. This SCU AE is aimed towards extending and enhancing GE MAC Electrocardiograph units that are operating in customer environments where DICOM Modality Worklist Servers are used for order management in add ition to the MUSE Server or in the absence of a MUSE server.

If the MUSE se rver does no t exist in such an environment, this SCU AE will be part of the MUSE DICOM Gateway Pro and will allow the GE MAC Electrocardiograph units to download orders from the MWL SCP.

If the MUSE does e xist in such an enviro nment, this SCU AE is require d only if an HL7 ADT/Orders interface is not available, or a Modality Worklist interface is preferred by the customer in lieu of the HL7 ADT/Orders.

The following re al-world activities will cause the Modality Worklist SCU AE to trigger a query to a Modality Worklist SCP:

1. An operator on a GE MAC Electrocardiograph uses a barcode scanner to

scan the barcode on a paper based order, or enters the Patient ID in the Patient demographics screen to request a “Patient Demographic” query.

Page 27

GE Healthcare

2. Alternatively, the operator on a GE MAC Electrocardiograph uses the Order

Manager Module to request “Open Orders” to be executed.

3. If the query from the electrocardiograph device is for “Patient

Demographics” then MUSE will look up the patient details from its database and send the patient data o bject to the electrocardiograph.

4. If the quer y is for an “Open Orders” list: A. The MUSE DICOM interface looks into its database and composes a list

of any open orders. It then sends the list of open orders back to the GE MAC Electrocardiograph.

B. If there are no open orders in the MUSE database at this time, the

following actions take place.

a. The MUSE DICOM interface would trigger a Moda lity Worklist query

for the ECG modalities with query parameters configured in the MUSE interface to the remote Modality Worklist SCP AE using the Modality Worklist SCU AE.

b. Upon receiving the response from the remote Modality Worklist SCP

c. I f there are no new worklist items in the response, then MUSE will send

2.3 AE SPECIFICATIONS

This section provides the specifications for all the Application Entities supported by MUSE 9.0\MUSE DICOM Gateway Pro.

2.3.1 AE Specification - All Applica t ion Entities

AE, MUSE will parse the worklist items and matches t hem against the entries in its database for their current status.

If there are any new worklist items in the response:

i. MUSE will create the corresponding entries in the MUSE database

for the Patients, Orders and Visit information obtained from the Modality Worklist item.

ii. The MUSE interface will mark these new entries as open Orders, and

composes an open Orders list and send it back to the requesting Electrocardiograph to complete the workflow.

an empty response to GE MAC Electrocardiograph.

This section provided a list of Application AE attributes that are common across all the AEs supported in MUSE. The individual AEs to which these sections are applic able will have refer back to this section.

Page 28

Maximum Length of PDU

65535 Bytes ( Configurable )

SOP Class name

SOP Class UID

DICOM Application Context Name

1.2.840.10008.3.1.1.1

Implementation Class UID

1.2.840.113619.6.302

GE Healthcare

2.3.1.1 Maximum Length of Protocol Data Unit

The Maximum Length of Protocol Data Unit (PDU) negotiation is included in all association establishment requests. The Maximum Length of PDU proposed for all associations initiated by the MUSE is configurable and is up to:

The number given above (65535 bytes) is also the Maximum Length of PDU in all DICOM associations that the interface can accept.

MUSE does not support SOP class Extended Negotiation in any DICOM associations i ts AEs accept.

The user information items sent by the AEs of MUSE are:

• Maximum Length of PDU

• Implementation Class UID

• Implementation Version Name

2.3.1.2 Association Policies

This section describes the common behaviors of all Application Entities of the MUSE DICOM interface with respect to the DICOM netwo rk association establishment. Specific behaviors of each individual AE will be describ ed in the respective Application Entity Specification sections.

2.3.1.2.1 General

The DICOM Application Context Name (ACN) proposed by the MUSE for all Application Entities is:

2.3.1.2.2 Asynchronous Nature

MUSE Application Entities DO NOT support asynchronous operations (i.e. multiple concurrent operations in one association). All operations will be performed synchronously.

2.3.1.2.3 Implementation Identifying Information

All MUSE AEs provide the same implementation class UID, which is:

Page 29

Implementation Version Name

MUSE_9.0

Presentation Context Table

List name

Name list

UID list

Transfer Syntax List 1

Explicit VR Little Endian

1.2.840.10008.1.2.1

Implicit VR Little Endian

1.2.840.10008.1.2

Explicit VR Big Endian

1.2.840.10008.1.2.2

GE Healthcare

All MUSE AEs provide the same implementation version name, which is:

Any exception to this is not ed under the respective AE Specification.

2.3.1.2.4 Transfer Syntaxes Supported

The following table shows the transfer syntaxes supported by all the Application Entities in the MUSE DICOM interface:

TABLE 1

2.3.1.3 Timers

2.3.1.3.1 Association Ti mers

MUSE supports an association timer for an association in which MUSE plays the role of an association initiator. The association timer starts when the association request is sent and stops when the association is established.

2.3.1.3.2 Operation Inactivity Timer

MUSE supports an operation inactivity timer for an association in which MUSE plays the role of an association initiator. The operation inactivity timer restarts every time a DIMSE service request has been issued.

2.3.2 AE Specification – MUSE DICOM Storage Service (SCU)

The MUSE DICOM Storage Service (SCU) Application Entity provides Standard Conformance to the following DICOM SOP Classes as an SCU.

Verification SOP Class 1.2.840.10008.1.1 Yes No 12-lead ECG Waveform Storage 1.2.840.10008.5.1.4.1.1.9.1.1 Yes No

SOP Class Name SOP Class UID SCU SCP

Page 30

GE Healthcare

General ECG Waveform Storage 1.2.840.10008.5.1.4.1.1.9.1.2 Yes No Encapsulated PDF Storage 1.2.840.10008.5.1.4.1.1.104.1 Yes No Storage Commitment Push Model 1.2.840.10008.1.20.1 Yes No

TABLE 2: SOP CLASSES SUPPORTED BY STORAGE SCU AE

Note: The MUSE DICOM Storage Service (SCU) AE us es the sa me AE title for requesting both storage and

storage commit ment from the SCP. Hen ce MUSE provides a single confi guration for the AE title for both Storage and Stora ge Commitment. However, the MUSE DICOM Storage Servic e (SCU) AE uses a diff erent port for receiving t he N-Event-Report for storage commitment. The remote SCPs need t o con fig ure t he st ora ge commitment port of the SCU using the same AE details as the Storage SCU details, but with a different port number.

For every SOP instance that MUSE transmits to a remote AE either manually or due to an automatic routing rule, MUSE sends a storage commitment request provided it is configured to do so and only if the remote AE supports storage commitment.

The MUSE DICOM Storage Service (SCU) Application Entity proposes a presentation context for the Storage Commitment – PUSH Model SOP Class as a dedicated association, or in a single association together with presentation contexts for DICOM Storage SOP Classes.

2.3.2.1 Association Establishment Policies

Please refer to 2.3.1 for the common association polices that are applicable for all Application Entities. This section describes polic ies and/or deviations that are applicable to this Application Entity.

2.3.2.1.1 General

Please refer to 2.3.1.2.1 for the Application Context Name presented by this Application Entity.

Please refer to 2.3.1.1 for the maximum PDU receive size for this Application Entity.

2.3.2.1.2 Number of Associations

The MUSE DICOM Storage Service (SCU) will initiate a maximum of 5 simultaneous associations to remote nodes.

The maximum number of concurrent associations that the MUSE DICOM Storage Service (SCU) Application Entity can initiate for sending the SOP Instances is configurable. By default this value is set to 5.

The M USE DICOM Storage Service (SCU) will support a maximum of 1 simultaneous associations initiated by remote nodes to receive N-Event-Reports for the outstanding Storage Commitment transactions.

Page 31

GE Healthcare

2.3.2.1.3 Asynchronous Nature

Please refer to 2.3.1.2.2 for asynchronous association policy for this Application Entity.

2.3.2.1.4 Implementation Identifying Information

Please refer to 2.3.1.2.3 for Implementation Identification information for this Application Entity.

2.3.2.2 Association Initiation Policy

When the MUSE DICOM Storage Service (SCU) Application Entity initiates an association for any real-world activity, it will propose the Presentatio n Contexts for all real-world activities; i.e., there is only a single, comprehensive Presentation Context Negotiation proposed for the AE.

The MUSE DICOM Storage Service (SCU) proposes only a single Transfer Syntax in each Presentation Context; i.e., for each Abstract Syntax in the following Presentation Context Tables, the AE proposes one Presentation Context for each specified Transfer Syntax.

Provided the Storage Commitment request has been configured in MUSE, the MUSE DICOM Storage Service (SCU) Application Entity will queue a request for storage commitment in an internal queue. This request will be processed by a dedicated thread that sends the storage commitment requests to the storage commitment SCU in a different association.

Storage SCU Application Entity will initiate associations only to those remote AEs configured in the “Permissible Remote Destination” devices in MUSE.

2.3.2.2.1 Real-World Activity - Se nd SOP Instance(s) to Remote AE

2.3.2.2.1.1 Associated Real-World Activity

When ECG tests are selected from MUSE based on the automatic routing rules, or manual GUI events in the MUSE Edito r application where a routing to a remote AE is initiated, the Storage requests are entered into a send queue.

These requests are processed by the MUSE DICOM Storage Service (SCU) Application Entity one b y one. Stora ge SCU AE accepts help from other MUSE software modules to construct the DICOM Information Object(s) as appropriate for the test(s) referred by the queue requests.

The MUSE DICOM Storage Service (SCU) Application Entity will then initiate an association with the remote AE indicated in the queue request.

If the association request is declined or times out due to network issues, the request is marked for retry as configured in MUSE. The number of retries is configurable in MUSE. The default is set to three tries.

Page 32

Test type in MUSE

DICOM IOD

SOP Class

12-lead ECGs 12-lead ECG Waveform Storage

1.2.840.10008.5.1.4.1.1.9.1.1 Encapsulated PDF Storage

1.2.840.10008.5.1.4.1.1.104.1

12-lead ECGs General ECG Waveform Storage

1.2.840.10008.5.1.4.1.1.9.1.2 Encapsulated PDF Storage

1.2.840.10008.5.1.4.1.1.104.1

15-lead ECGs General ECG Waveform Storage

1.2.840.10008.5.1.4.1.1.9.1.2 Encapsulated PDF Storage

1.2.840.10008.5.1.4.1.1.104.1

All other test types

Encapsulated PDF Storage

1.2.840.10008.5.1.4.1.1.104.1

GE Healthcare

If the association is successfully negotiated, the MUSE DICOM Storage Service (SCU) Application Entity will perform C-STORE operation to support this real-world activity.

The MUSE DICOM Storage Service (SCU) Application Entity can perform multiple CSTORE operations over one single association. If the request contains multiple SOP Instances then multiple C-STORE requests will be issued over the same association. The MUSE DICOM Storage Service (SCU) Application Entity does not use the C-STORE priority attribute.

The MUSE DICOM Storage Service (SCU) Application Entity will propose all presentation contexts as the list of SOP Instances to be sent dictates, and will send all SOP Instances as long as the required presentation contexts are accepted.

Upon receiving a C-STORE-RSP containing a “Success” status, the MUSE DICOM Storage Service (SCU) Application Entity will perform the next C-STORE operation. The association will be maintained if possible.

Upon recei ving a C-STORE-RSP that contains a “Refused” status, the Storage SCU AE will terminate the association. The remaining SOP Instances will not be transmitted.

Upon receiving a C-STORE-RSP which contains any status other than “Success or Refused,” the Storage SCU AE will consider the current request to be “Failure,” but will continue to attempt to send the remaining SOP Instances on the same association.

2.3.2.2.1.1.1 Data Retrieval from MUSE Using the Store SCU

MUSE can be configured to send not only the DICOM ECGs, but also DICOM ECGs that are stored in MUSE. Non-DICOM ECGs will be translated to a suitable DICOM IOD and transmitted to the remote AE based on the receiving AE titles’ capabilities.

The following table describes the test types in MUSE and the corresponding DICOM IOD that would be attempted by MUSE based on the remote AE capabilities. The automatic selection can be overruled in MUSE through configur ation elements.

<= 500 Hz, <= 10 sec

<= 500 Hz, > 10 sec

all frequencies, all durations

TABLE 3: MUSE TEST TYPE TO DICOM IOD TRANSLATION RULES

Page 33

Explicit VR Little Endian

Explicit VR Big Endian

1.2.840.10008.1.2.1

1.2.840.10008.1.2.2

Explicit VR Little Endian

Explicit VR Big Endian

1.2.840.10008.1.2.1

1.2.840.10008.1.2.2

Explicit VR Little Endian

Explicit VR Big Endian

1.2.840.10008.1.2.1

1.2.840.10008.1.2.2

GE Healthcare

Note: As pointed out previously, SOP Instances sent to the remote AE may have undergone correction /

modification in certain data elements. A list of the data elements that may undergo data coercion is given in

2.3.3.2.1.7

2.3.2.2.1.1.2 Sending the Origina l IOD as Received

MUSE can be configured to send a 12-lead ECG waveform, General ECG waveform, or an Encapsulated PD F in the original format and its original SOP Instance UID without any modification if it had been acquired into the MUSE system using the DICOM Storage SCP. If this option is selected, MUSE will ignore the translated test stored in M USE and send the o riginal IOD in the same format as it was received. All the private fields will be preserved and sent.

If the above option is not selected, MUSE will convert the latest version of the test in MUSE into a DICOM IOD and send it to the SCP. All the private fields received in the original IOD will be lost. The IOD that is tra nsmitted will contain any changes that were made to the fields in the MUSE after it was acquired.

If this option is selected, but the test is a No n-DICOM ECG stored 30

in the MUSE, the option will be ignored and the Non-DICOM ECG will be converted to DICOM and sent to the SCP.

2.3.2.2.1.2 Proposed Presenta tion Context Table

The following table shows the Presentation Contexts proposed by MUSE DICOM Storage Service (SCU) Application Entity to remote AEs to send DICOM SOP Instances:

Presentation Context Table – Proposed by AE MUSE DICOM Storage Service (SCU) for Activity Send SOP Instance(s)

to Remote AE

Abstract Syntax Transfer Syntax Role

Name UID Name List UID List

12-lead ECG Waveform Storage

General ECG Waveform Storage

Encapsulated PDF Storage

1.2.840.10008.5.1.4.1.1.9.1.1

1.2.840.10008.5.1.4.1.1.9.1.2

1.2.840.10008.5.1.4.1.1.104.1

Implicit VR Little Endian

1.2.840.10008.1.2

SCU None

Extended

Negotiation

TABLE 4: PROPOSED PRESENTATION CONTEXTS BY STORAGE SCU AE

NOTE: Please note that based on the test type listed in Table 4: Proposed Presentation Contexts

by Storage SCU AE

, the SCU would present either 12-lead and Encapsulated PDF or General Waveform

Page 34

Service status

Further meaning

Error code

Behavior

Success

Image transmitted

0000

Image successfully sent. The send request in the queue is marked SUCCESS

Refused

Out of Resource

A700

The send request in the queue is set for RETRY.

Error

Dataset does not match SOP class

A900

The send request in the queue is set for FAILED.

Cannot Understand

C000

The send request in the queue is set for RETRY.

Warning

Coercion of data elements

B000

The send request in the queue is set to a SUCCESS.

Dataset does not match SOP class

B007

The send request in the queue is set to a FAILED.

Elements discarded

B006

The send request in the queue is set to a SUCCESS.

Exception

Behavior

Timeout

The Association is aborted using A-ABORT and the command is marked as failed. The reason is logged and reported to the user.

Association aborted

The command is marked as failed. The reason is logged and reported to the user.

GE Healthcare

and Encapsulated PDF in its Proposed Presentation Context, never all three. In order to send a SOP Instance, the Storage SCU Application Entity requires the remote Storage SCP to select the presentation context that matches the SOP Instance that is stored in MUSE. Otherwise, the Storage SCU Application Entity will not be able to send the SOP Instance.

In case more than one presentation context is accepted by the remote AE, MUSE will choose either 12-lead OR General Waveform IOD to be sent to the receiving AE. Encapsulated PDF is the least preferred IOD.

2.3.2.2.1.2.1 SOP Specific DICOM Conformance Statement for All Storage SOP Classes

If configured to send the original IOD, all private elements, which exist in the Storage SOP Instance, will be sent. The existence of private elements depends on the equipment that is sending SOP Inst ances to the MUSE.

2.3.2.2.1.2.1.1 C-STORE-RESPONSE processing

The Storage SCU Application Entity has the following command response behavior:

TABLE 5: COMMAND RESPONSE STATUS HANDL I NG IN STORAGE SCU AE

The behavior of the Storage SCU Application Entity during communication failure is summarized in a table as follows:

Page 35

GE Healthcare

TABLE 6: COMMAND COMMUNICATION FAILURE BEHAVIOR OF STORAGE SCU AE

2.3.2.2.1.2.1.2 Extended Character Sets

MUSE may perform data coercion in a SOP Instance sent out while updating the dataset with the information maintained in the MUSE database. MUSE will support the character sets as listed in 2.7. The Patient Name can be encoded using any of the sets in the list.

If a Kanji name is present for the patient, MUSE will send the Kanji name in the Phonetic Patient name encoded using ISO-IR-87 character set.

In the current release, MUSE will not add text information encoded with extended character sets into other data elements.

2.3.2.3 Association Acceptance Policies

The MUSE DICOM Storage Service (SCU) will listen on a configurable port for NEVENT-REPORT corresp onding to all the outstanding storage commitment transactions. The remote storage commitment SCP is expected to open an unsolicited association to send an N-EVENT-REPORT response for t he se requests.

2.3.3 AE Specification – MUSE DICOM Storage Service (SCP)

The MUSE DICOM Storage Service (SCP) Application Entity provides Standard Conformance to the following DICOM SOP Classes as an SCU:

SOP Class Name SOP Class UID SCU SCP

Verification SOP Class 1.2.840.10008.1.1 No Yes 12-lead ECG Waveform Storage 1.2.840.10008.5.1.4.1.1.9.1.1 No Yes General ECG Waveform Storage 1.2.840.10008.5.1.4.1.1.9.1.2 No Yes Encapsulated PDF Storage 1.2.840.10008.5.1.4.1.1.104.1 No Yes Storage Commitment Push Model 1.2.840.10008.1.20.1 No Yes

TABLE 7: SOP CLASSES SUPPORTED BY STORAGE SCP AE

2.3.3.1 Association Establishment Policies

Please refer to 2.3.1 for the common association polices that are applicable for all Application Entities. This section describes po licies and/or deviations that are applicable to this Application Entity.

Page 36

GE Healthcare

2.3.3.1.1 General

Please refer to 2.3.1.2.1 for the Application Context Name presented by this Application Entity.

Please refer to 2.3.1.1 for the maximum PDU receive size for this Application Entity.

2.3.3.1.2 Number of Associations

The DICOM Storage Service (SCP) will be able to accept a maximum of 5 associations from a remote AE.

The maximum number of concurrent associations that the DICOM Storage SCP Application Entity can accept for receiving SOP Instances is configurable. By default this value is set to 5.

The maximum number of concurrent associations that the DICOM Storage SCP Application Entity can initiate for sending a Storage Commitment Response is set to 1.

2.3.3.1.3 Asynchronous Nature

Please refer to 2.3.1.2.2 for asynchronous association policy for this Application Entity.

2.3.3.1.4 Implementation Identifying Information

Please refer to 2.3.1.2.3 for Implementation Identification information for this Application Entity.

2.3.3.2 Association Acceptance Policy

The DICOM Storage Service (SCP) Application Entity initiates a DICOM association to send Storage Commitment responses to a remote AE, in response to a previously received Storage Commitment request. Apart from this, the DICOM Storage Service (SCP) does not initiate any associations with remote nodes.

MUSE accepts association only from tho se remote AEs that are in its list of registered AEs.

MUSE uses a single AE for both Storage and Storage Commitment. Hence MUSE provides a single configuration for both Storage and Storage Commitment services.

2.3.3.2.1 Real-World Activity - Receive SOP Instance from Remote AE

2.3.3.2.1.1 Associated Real-World Activity

When a DICOM based electrocardiograph user selects the ECGs to be transmitted to MUSE and initiates a transmission, the Storage SCU AE in the remote device initiates a DICOM Association Request to MUSE.

Page 37

GE Healthcare

There is no local real-world activity required for the MUSE DICOM Storage Service (SCP) AE to respond to incoming DICOM associations to receive SOP Instances. The MUSE DICOM Storage Service (SCP) AE is always listening for an incoming association and will automatically respond to a request. This includes verification requests.

Upon receiving a SOP Instance, the MUSE DICOM Storage Service (SCP) AE will start the following local real-world activities:

1. Profile the received SOP Instance to an ordered study or create a new study

(unordered study) if no match is found.

2. Each incoming ECG is parsed and stored in the internal MUSE database in the

format internal to MUSE.

: The Storage SCP AE always saves a successfully received SOP Instance. However, the MUSE

Note

DICOM Storage Servic e (SCP) (successfully parsed into MUSE). It is highly recommended that the remote AE submitting data to MUSE Storage SCP AE verifies the acquisition by sending a Storage Commitment request.

AE does not guarantee that the data will be acquired into the MUSE database

2.3.3.2.1.1.1 Description and Sequencing of Activities

1. If the association request is accepted by MUSE, the remote AE can start transmitting

the ECGs through C-STORE operations.

2. Storage SCP Application Entity can support multiple C-STORE operations over a

single association. If the remote AE needs to send multiple SOP Instances then multiple C-STORE requests can be issued over the same association. The Storage SCP Application Entity does not use the C-STORE priority attribute.

3. The MUSE DICOM Storage Service (SCP) Application Entity can support many

presentation contexts.

4. Upon receiving a SOP Instance, the MUSE DICOM Storage Service (SCP) AE

would validate the SOP Instance and send a C-STORE-RSP conta ining a “Success” status if there are no errors. The SOP Instance is then submitted for parsing and storage in MUSE to the acquisition request queue.

5. If any issues are found at this stage, the MUSE DICOM Storage Service (SCP)

Application Entity would send a C-STORE-RSP containing a “Failure” status.

6. If there are issues with the permission of the remote AE, for example, licensing or

network issues, etc., that prevent the received SOP Instances from being submitted for acquisition, a C-STORE-RSP of a “Refused” status is returned.

7. The remote Storage SCU AE can then perform the next C-STORE operation. The

association will be maintained by the Storage SCP Application Entity if possible.

Page 38

Explicit VR Little Endian

1.2.840.10008.1.2.1

Explicit VR Little Endian

1.2.840.10008.1.2.1

Explicit VR Little Endian

1.2.840.10008.1.2.1

Explicit VR Little Endian

1.2.840.10008.1.2.1

Service

Status code

Further

Status code sendi ng explanati on

Related fields

SCU

Success

0000

Image Accepted

Image successfully received to a Study object in the MUSE.

None Refused

A700

Out of Resource

Processing of Store Requests cannot be

None

GE Healthcare

2.3.3.2.1.2 Accepted Presentation Context Table

The following table shows the presentation contexts acceptable for this Application Entity for receiving SOP Instances.

Presentation Context Table - Accepted by AE DICOM Storage Service (SCP) for Activity Receive SOP Instance from

Remote AE

Abstract Syntax Transfer Syntax Role

Name UID Name List UID List

Verification SOP Class

12-lead ECG Waveform Storage

General ECG Waveform Storage

Encapsulated PDF Storage

1.2.840.10008.1.1

1.2.840.10008.5.1.4.1.1.9.1.1

1.2.840.10008.5.1.4.1.1.9.1.2

1.2.840.10008.5.1.4.1.1.104.1

Implicit VR Little Endian Explicit VR Big Endian

1.2.840.10008.1.2

1.2.840.10008.1.2.2

1.2.840.10008.1.2

1.2.840.10008.1.2.2

1.2.840.10008.1.2

1.2.840.10008.1.2.2

1.2.840.10008.1.2

1.2.840.10008.1.2.2

TABLE 8: ACCEPTABLE PRESENTATION CONTEXT FOR STORAGE SCP AE

2.3.3.2.1.2.1 SOP Specific Conformance Statement for all Storage SOP Classes

The MUSE DICOM Storage Service (SCP) Application Entity provides standard conformance to the DICOM Storage Service Class as SCP. No specialized or privatized Storage SOP Class can be accepted.

This Application Entity conforms to the DICOM Storage SOP Classes at Level 2 (full) as specified in DICOM Standard PS 3.4, Appendix B.4.1. No elements are discarded. All private data elements (including Unknown VR data element) will be accepted and stored as is.

Extended

Negotiation

SCP None

2.3.3.2.1.3 C-STORE Response Status

status

The Storage SCP Applica tion Entity will abort the association with an A-ABORT when the processing of store requests cannot be completed due to system failures like MUSE middle-tier and/or the database subsystem failures.

The Storage SCP will return the following status codes in a C-STORE-RSP message:

meaning

send back to

Page 39

completed because the MUSE database subsystem is not functioning.

Error

A900

Cannot

Following generally required data elements in the

Series Instance UID

None

C000

Cannot

Processing of Store Requests cannot be

to create new Patient / Study.).

Warning

B000

Coercion of data

Some data elements have been changed to suit

2.3.3.2.1.7 For details.

None

B007

Dataset does not

A valid dataset was received, but there is a

received.

None B006

Elements discarded

Some data elements have been discarded and are not stored in the MUSE database.

None

GE Healthcare

Understand

elements

match SOP class

SOP Instance missed:

SOP Instance UID SOP Class UID Study Instance UID

completed due to failure of Study Profiling (e.g., no match found and the called AE Title is unable

MUSE database elements an d storage.. See

mismatch between what is declared and what is

TABLE 9: STATUS CODES RETURNED I N C-STORE-RSP BY STORAGE SCP AE

2.3.3.2.1.4 SOP Instance Storage and Abnormal Association Termination

2.3.3.2.1.4.1 Data Caching

The Storage SCP Application Entity can cache several SOP I nstances in memory during the receipt operation. After each SOP Instance is received, the SCP will acknowledge the receipt of the instance with a C-STORE-RSP, but will not necessarily write it to the MUSE storage system. MUSE will store the instance to the MUSE storage system only after it finishes the internal processing of the message. This will be an asynchronous operation and can continue even if the association is closed. To verify whether the instance was successfully stored to the MUSE, the SCU should use the storage commitment service.

2.3.3.2.1.4.2 SOP Instance Storage Status Conditions in the SCP

It is possible for this Storage SCP Applic ation Entity to fail in a manner where the cached data is unrecoverable, such as a power failure. The remote SCU shall use the following rules to decide if the transmitted SOP Instances have been stored safely in MUSE:

• If the remote SCU issues an association abort (A-ABORT) or receives a provider-initiated abort (A-P-ABORT) from this Storage SCP Application Entity, the success or failure of the Storage SCP to retain any object sent on the association is undefined.

• If an association is terminated because of any network operation failure or timeout, the ability of the Storage SCP Application Entity to retain any object sent on the association is undefined.

Page 40

Data Element

DICOM Size

Database Size

Behavior

Patient ID

64 Char

16 Char

The characters exceeding the size allowed by the database will be truncated. No warning returned to the SCU.

Patient Name

64 Char

Last name (40

The Patient Name will first be converted to the database

database. No warning returned to the SCU.

Patient Name

Ideographic

This name group will be ignored since MUSE database does not support this name.

Patient Name

Phonetic

64 char

Phonetic name is supported for Japanese Kanji names

since MUSE does not support them.

GE Healthcare

The remote SCU implementations are strongly recommended to use the DICOM Storage Commitment service to verify the permanent storage status of the submitted SOP Instances.

2.3.3.2.1.5 Data Elements of Unknown Value R e presentation

The SCP will store all unknown data elements as “unknown VR (UN)”. Therefore, besides the data change / correction, certain data elements may be recomputed for the sake of the data storage, like group length, sequence length, etc.

Some data fields in the MUSE database may have a smaller field size than the size specified in the DICOM Standard. Any data values exceeding the field size of the database will be truncated:

(Alphabetic)

TABLE 10: DATA ELEMENTS THAT MAY BE TRUNCATED WHEN STORED IN MUSE DATABASE

Char), First name (20 Char)

2.3.3.2.1.6 Test Type Mapping for Received SOPs

MUSE determines the type of ECG received using the DICOM tag (0008,0060). Since MUSE supports only the 12 lead and general ECG waveform IODs, these are mapped to the type “ECG” in MUSE. In the case of encapsulated PDFs, MUSE will not be able to determine the difference between ECG, Stress and Holter, hence all these tests will be mapped to “ECG” and displayed as “ECG” in the MUSE UI.

2.3.3.2.1.7 Data Coercion

format (see Table 11: Data Elements that might be

impacted by Coercion of SOP Instances

truncated if the size exceeds the size allowed by the

that might be sent to the MUSE encoded using ISO-IR-87. Names sent encoded in other character sets will be dropped

) and then

When MUSE receives SOP Instances, some of the DICOM data elements in the SOP Instance(s) could change. There are several reasons why this could happen and why it is necessary.

MUSE either uses interfaces to customer IS products like HIS/EMR systems or its own internal capabilities to create Patient / Study data. MUSE always assumes that the data from the HIS/EMR is the “source,” as its Patient / Study data is more accurate than the

Page 41

Attribute Name

Tag

Change Reason

Patient ID

(0010,0020)

SOP Instance is as sociated to another patient, or wrong Patient ID is included in the dataset.

Patient's Name

(0010,0010)

Wrong data in dataset. Most likely manual

character sets.

Patient's Birth Date

(0010,0030)

Wrong data in dataset . Most likely manual input.

Patient's Sex

(0010,0040)

Wrong data in dataset. Most likely manual input.

Other Patient IDs

(0010,1000)

Data corrected or supplemented.

Study Instance UID

(0020,000D)

SOP Instance is as sociated to another study.

private tags.

Accession Number

(0008,0050)

Wrong data in dataset. Most likely manual input.

Study Date

(0008,0020)

Study with multiple steps performed on

study date / time.

Study Time

(0008,0030)

See above.

Referring Physician's Name

(0008,0090)

Wrong data in dataset. Most likely manual input.

Study Description

(0008,1030)

Study with multiple steps performed on different devices; MUSE can only take one.

Requested Procedure ID

(0040,1001)

Data corrected or supplemented.

Series Instance UID

(0020,000E)

Series Instance UID is associated to another

dataset as private tags.

Series Number

(0020,0011)

User specific reasons.

SOP Instance UID

(0008,0018)

SOP Instance UID is associated to ano ther SOP

dataset as private tags.

Image Number

(0020,0013)

User specific reasons.

Number of Images in Acquisition

(0020,1002)

User specific reasons.

GE Healthcare

data received from the electrocardiographs’ transmitted SOP Instances. Therefore, the HIS/EMR information is always used to correct any data entry errors.

The following table lists all d ata elements of the SOP Instances that may undergo a data correction in MUSE. They can be different from the original values when a remote AE receives them from the Storage SCU AE of MUSE.

input. Please note that Pat ient Name may be multi-valued and encoded with extended

Please note, if these UID values are changed, the original values are saved in the dataset as

different devicea, MUSE takes th e ear liest

series. Please note, if these UID values are changed, the ori gi nal values are saved in the

Instance. Please note, if these UID values are changed, the ori gi nal values are saved in the

TABLE 11: DATA ELEMENTS THAT MIGHT BE IMPACTED BY COERCION OF SOP INSTANCES

2.3.3.2.1.8 Presentation Context Acceptance Criterion

The MUSE DICOM Storage Service (SCP) evaluates each Presentation Context independently and accepts any Presentation Context that matches an Abstract Syntax for any real-world activity.

Page 42

GE Healthcare

2.3.3.2.1.9 Transfer Syntax Selection Policies

Within each Presenta tion Conte xt, the MUSE DICOM Storage Service (SCP) will accept the first proposed transfer syntax that MUSE also supports for that Abstract Syntax.

2.3.3.3 Supported Uses of SOP Insta nces

MUSE is usua lly used in the Cardiology practice for ECG management, storage, display, print, distribution etc. This DICOM Conformance Statement specifies which DICOM Storage SOP Classes are supported by MUSE as Storage SCP, i.e., they can be received by MUSE. This does not automatically confirm that all SOP Instances can be displayed, printed and/or processed in MUSE applications. T his section provides information on the supported uses of those SOP Instances that can be received and successfully Normalized into MUSE.

2.3.3.3.1 Data Storage

MUSE will store all successfully received SOP Instances in its database.

2.3.3.3.2 Information Routing and Distribution

MUSE supports routing of received Studies to remote AE(s), as configured, upon successful receipt of the SOP Instances or a variety of status changes to the SOP Instance that was normalized to its database.

MUSE also provides its use rs the ability to manually select or run complex queries and direct the result set to remote AE(s).

2.3.3.3.3 Data Display

MUSE Editor and MUSE Web clients are able to display these SOP Instances.

2.3.3.3.4 Printing data

MUSE Editor is able to print these SOP Instances.

2.3.4 AE Specification - DICOM Storage Commitment Service – Push Model (SCU)

If configured, MUSE sends Storage Commitment requests to a remote Storage Commitment SCP for SOP Instances it transmits as a result of an automatic routing rule or manual initiation.

The Storage Commitment SCU Application Entity proposes a pre sentation context for the Storage Commitment – PUSH Model SOP Class as a dedicated association, or in a single association together with presentation contexts for DICOM Storage SOP Classes.

The Storage Commitment SCU Application Entity provides Standard Conformance to the following SOP Classes as SCP:

Page 43

GE Healthcare

SOP Class Name SOP Class UID SCU SCP

Storage Commitment (Push model) 1.2.840.10008.1.20.1

TABLE 12: SOP CLASS SUPPORTED FOR STORAGE COMMITMENT REQUEST IN MUSE DICOM STORAGE SCP AE

: The MUSE DICOM Storage Service (SCU) AE uses the same AE title for requesting both storage and

Note

storage commitment from the SCP. Hence MUSE provides a single configuration for the AE title for both Storage an d Storage Commitment . However, the MU SE DICOM Storage Servi ce (SCU) AE uses a different port for receiving t he N-Event-Report for sto rage c ommi tm ent .Th e remot e SCPs need to c onf igu re th e st orage commitment port of the SCU using the same AE details as the Storage SCU details but different port number.

2.3.4.1 Association Establishment Policies

Please refer to 2.3.1 for the common association polices that are applicable for all Application Entities.

2.3.4.1.1 General

Please refer to 2.3.1.2.1 for the Application Context Name presented by this Application Entity.

Please refer to 2.3.1.1 for the maximum PDU receive size for this Application Entity. The maximum number of concur rent asso ciati ons and the maximum PDU size for MUSE

DICOM Storage Commitment (SCU) Application Entity is the same as the maximum concurrent associations and maximum PDU size configured for the Storage SCU. A separate configuration is NOT provided for the Storage Commitment.

Yes No

2.3.4.1.2 Asynchronous Nature

Please refer to 2.3.1.2.2 for asynchronous association policy for this Application Entity.

2.3.4.1.3 Implementation Identifying Information

Please refer to 2.3.1.2.3 for Implementation Identification information for this Application Entity.

2.3.4.2 Association Acceptance Policies

The MUSE DICOM Storage Service (SCU) will listen on a configurable port for NEVENT-REPORT corr esponding to all the outstanding storage commitment transactions. The remote storage commitment SCP is expected to open an unsolicited association to send an N-EVENT-REPORT response for these requests.

Page 44

Explicit VR Little Endian

Explicit VR Big Endian

1.2.840.10008.1.2.1

1.2.840.10008.1.2.2

GE Healthcare

2.3.4.2.1 Real-World Activity - Receive Storage Commitment Response from Remote AE

2.3.4.2.1.1 Associated Real-World Activity

2.3.4.2.1.1.1 Description and Sequencing of Activities

The following re al-world activities are associated with the Sending Stor age Commitment response receive operation.

1. Remote Storage Commitment SCP initiates an unsolicited N-EVENT-REPORT on a

dedicated association. No operator intervention is required to receive these reports.

2. Upon receipt of N-EVENT-REPORT, the MUSE DICOM Storage Service (SCU)

Application Entity will inspect the response and perform the following:

• If MUSE is functioning as a forwarding node to a DICOM destination, it will

delete the local copy of the SOP Instance for which a “Successful” response was received.

• Otherwise, MUSE will mark the transmission requests that caused these

responses a “Success.”

2.3.4.2.1.2 Accepted Presentation Context Table

Presentation Context Table – Accepted by AE DICOM Storage Service (SCU) for Activity Receive storage

commitment response from Remote AE

Abstract Syntax Transfer Syntax Role

Name UID Name List UID List

Storage Commitment (Push model)

TABLE 13: ACCEPTED PRESENTATION CONTEXT FOR STORAGE COMMITMENT BY STORAGE SCU AE

2.3.4.2.1.2.1 SOP Specific DICOM Conformance Statement for Storage Commitment (Push Model)

1.2.840.10008.1.20.1

The DICOM Storage Service (SCU) will support SCU/SCP Role Reversal selection negotiation for the presentation contexts of the Storage Commitment - PUSH Model SOP Class.

Storage SCU Application Entity uses a N-EVENT-REPORT DIMSE service element for the Storage Commitment response processing. Once the response is received, the following actions will be taken depending on the status of response.

Implicit VR Little Endian

1.2.840.10008.1.2

SCU SCU/SCP role

Extended

Negotiation

selection

Page 45

Attribute

Tag

Value

Transaction UID

(0008,1195)

Value received from SCP

Referenced SOP Sequence

(0008,1199)

Value received from SCP

> SOP Class UID

(0008,1150)

Value received from SCP

> SOP Instance UID

(0008,1155)

Value received from SCP

Attribute

Tag

Value

Transaction UID

(0008,1195)

Value received from SCP

Failed SOP Sequence

(0008,1198)

Value received from SCP

> SOP Class UID

(0008,1150)

Value received from SCP

> SOP Instance UID

(0008,1155)

Value received from SCP

Failure Reason

(0008,1197)

Value received from SCP

GE Healthcare

2.3.4.2.1.3 Commit response with SUCCESS status

The following attributes are expected as part of the dataset for N-EVENT-REPORT from the remote Storage Commitment SCP.

2.3.4.2.1.4 Commit Response with FAILURE Status

The following attributes are expected as part of the dataset for N-EVENT-REPORT from SCP:

The “Success” flag is set for the transmission request for all the successful instances. In case of complete/partial failure, the Storage SCU Application Entity would update the transmission request to “Failed” or “Partial Failure” and the request will be marked for a retry. The number of retries for a failed job is configurable in MUSE and is set to 3 by default. Retry requests will be treated as new requests and will go through the whole sequence of operations once again.

The failure reason, if returned by remote Storage Commitment SCP, will be logged as part of the status of the transmission request process. The failed SOP Instances will not be deleted if “Auto delete upon transmission” has been set on the remote AEs.

2.3.4.2.1.5 Presentation Context Acceptance Criterion

The MUSE DICOM Storage Service (SCU) evaluates each Presentation Context independent ly, and accepts any Presentation Context that matches an Abstract Syntax for any real-world activity.

2.3.4.2.1.6 Transfer Syntax Selection Policies

Within each Presentation Context, the MUSE DICOM Storage Service (SCU) will accept the first proposed transfer syntax that it also supports for that Abstract Syntax.

Page 46

GE Healthcare

2.3.4.3 Association Initiation Policy

Storage Commitment Requests are queued in MUSE right after a successful C-STORERSP is received for the transmitted SOP Instances. The remote AE to which the storage commitment requests are to be sent can either be the same as the remote AE to which the C-Store request was sent, or it can be a different AE. A separate Storage commitment thread will then initiate an association to the remote stor age commitment SCP to send the requests using N-ACTION.

MUSE allows different AE titles for the Storage Commitment request and the Store SCP in the remote AE configuration.

2.3.4.3.1 Real-World Activity - Send Storage Commitment Request to the Remote AE

2.3.4.3.1.1 Associated Real-World Activity

If the remote AE is configured to support Storage Commitment, and MUSE is configured to take advantage of this option, the MUSE DICOM Storage Service (SCU) Application Entity will initiate a request for Storage Commitment. The following DIMSE service elements are supported for the Storage Commitment request processing.

As explained earlier, the SOP Instances in the selected tests are sent to the remote Storage SCP AE using DICOM C -STORE operations.

• If there are any C-STORE-RSP failures in the transfers, the Storage Commitment

request will not be sent. The corresponding send request will be marked as “Failed” and the user will be notified of the request’s status.

• For the SOP Instances for which a C-STORE-RSP of “Success” is received, the

Storage SCU Application Entity initiates DIMSE N-ACTION r equesting Stora ge Commitment in a separate association.

• The Storage SCU Application Entity then waits for an N-ACTION-REPORT

from the Storage Commitment SCP on a different association for a configurable amount of time. This association has to be initiated by the remote Storage Commitment SCP.

• Storage SCU Application Entity will then change the transmission request status

to “Waiting for Storage Commitment” indicating the request is waiting for the response from the remote Storage Commitment SCP AE.

• Storage SCU Application Entity will eventually mark the request as “Failed” if

the response is not received within the stop time. Stop time is the maximum duration the request can wait for responses. Optionally these failed attempts could be retried.

• A New transaction UID will be created for each retry by the user. The old

transaction UID is not applicable for these requests.

Page 47

Data Element

Tag

Description

Value sent to the SCP

Transaction UID

(0008,1195)

UID to identify this request

YES

Referenced SOP Sequence

(0008,1199)

A list of SOP Instances for which storage commitment is requested

YES

> Referenced SOP Class UID

(0008,1150)

SOP Class UID of the instance

YES

> Referenced SOP Inst ance UID

(0008,1155)

SOP Instance UID of the instance

YES

GE Healthcare

2.3.4.3.1.2 Proposed Presenta tion Context Table

The following table shows the Presentation Context proposed by the MUSE DICOM Storage Service (SCU) Application Entity when requesting Storage Commitment to remote AEs to send DICOM SOP Instances:

Presentation Context Table - Proposed by AE The MUSE DICOM Storage Service (SCU) for Activity Send Storage

Commitment Request to the Remote AE

Abstract Syntax Transfer Syntax Role

Name UID Name List UID Li st

Storage Commitment Push Model

1.2.840.10008.1.20.1

Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian

1.2.840.10008.1.2

1.2.840.10008.1.2.1

1.2.840.10008.1.2.2

SCU None

Extended

Negotiation

TABLE 14: PROPOSED PRESENTATION CONTEXT FOR STORAGE COMMITMENT REQUESTS BY STORAGE SCU AE

2.3.4.3.1.2.1 SOP Specific DICOM Conformance Statement for the Storage Commitment Push Model SOP Class SCU

The DICOM Storage Commitment (SCU) will only accep t the SCU role (which must be proposed via SCP /SCU Role Selection Negotiatio n) within a Presentation Context for the Storage Commitment Push Model SOP Class.

Upon receiving a Storage Commitment N-EVENT-REPORT (Storage Commitment Result), the DICOM Storage Service (SCU) will validate the Transaction UID against its list of outstanding Storage Commitment Request Transaction UIDs. If it matches an outstanding Request, the AE will mark all SOP Instances for which a success status is indicated as archived and change the status of the corresponding storage request from “waiting for storage commitment” to “Success.”

If the Storage Commitment Result indicates any failure status, the status of the corresponding storage request will be changed to "Failed." The storage and storage commitment for the corresponding transaction will be attempted again for a configurable number of times before failing the request permanently. An error message will be logged, including the Failure Reason (0 008,1197 ) attribute values.

TABLE 15: DATA ELEMENTS SENT IN STORAGE COMMITMENT REQUEST BY STORAGE SCU AE

The Storage SCP AE provides the following data elements in the dataset in its request:

Page 48

Data Element

Tag

Description

Value sent to the SCP

Storage Media File-Set ID

(0088,0130)

The DICOM File-Set from all SOP Instances can be retrieved.

Not Set

Storage Media File-Set UID

(0088,0140)

Referenced Study Component Sequence

(0008,1111)

The Study Component that

in the referenced SOP sequence.

Not set

GE Healthcare

The Storage SCU AE does not use the following data elements in a Storage Commitment request.

contains all SOP Instances listed

TABLE 16: DATE ELEMENTS UNUSED IN STORAGE COMMITMENT REQUEST BY STORAGE SCU AE

The MUSE DICOM Storage Service (SCU) does not send back any status codes to the SCP in its response N-Event-Report except for success (0000). In case of failure, the DICOM Storage Service (SCU) will log the error internally.

2.3.5 AE Specification - DICOM Storage Commitment Service – Push Model (SCP)

The MUSE DICOM Storage Commitment (SCP) Application Entity provides Standard Conformance to the following DICOM SOP Classes as an SCU:

SOP Class Name SOP Class UID SCU SCP

Storage Commitment Push Model 1.2.840.10008.1.20.1 No Yes

TABLE 17: SOP CLASSES SUPPORTED BY STORAGE COMMITMENT SCP AE

2.3.5.1 Association Establishment Policies

2.3.5.1.1 General

Please refer to 2.3.1.2.1 for the Application Context Name presented by this Application Entity.

Please refer to 2.3.1.1 for the maximum PDU receive size for this Application Entity.

2.3.5.1.2 Number of Associations

The DICOM Storage Service (SCP) will be able to accept a maximum of 5 associations from a remote AE.

Page 49

GE Healthcare

The maximum number of concurrent associations that the DICOM Storage SCP Application Entity can accept for receiving SOP Instances is configurable. By default this value is set to 5.

The maximum number of concurrent associations that the DICOM Storage SCP Application Entity can initiate for sending Storage Commitment Response is set to 1.

2.3.5.1.3 Asynchronous Nature

Please refer to 2.3.1.2.2 for asynchronous association policy for this Application Entity.

2.3.5.1.4 Implementation Identifying Information

Please refer to 2.3.1.2.3 for Implementation Identification information for this Application Entity.

2.3.5.2 Association Initiation Policy

The DICOM Storage Commitment Service (SCP) Application Entity initiates a DICOM association to send Storage Commitment responses to a remote AE, in response to a previously received Storage Commitment requests. MUSE accepts association only from those remote AEs that are in its list of registered AEs.

2.3.5.2.1 Real-World Activity - Send Storage Commitment response to remote AE

2.3.5.2.1.1 Associated Real-World Activity

The MUSE DICOM Storage Commitment (SCP) Application Entity initiates a DICOM association to send Storage Commitment responses to a remote AE, in response to previously received Storage Commitment requests.

2.3.5.2.1.1.1 Description and sequencing of activities

The MUSE DICOM Storage Commitment (SCP) AE will always initiate a new DICOM association to send DICOM Storage Commitment responses. It will never send a DICOM Storage Commitment response in the same DICOM association in which a request was received.

The MUSE DICOM Storage Commitment (SCP) AE will always initiate one single DICOM association for sending the Storage Commitment report simultaneously. Multiple Storage Commitment reports will be sent subsequently.

2.3.5.2.1.2 Proposed Presentation Context

The MUSE DICOM Storage Commitment (SCP) Application Entity will propose the following presentation context to send a Storage Commitment report to a remote AE.

Page 50

Storage Commitment –

1.2.840.10008.1.20.1

Explicit VR Little Endian

1.2.840.10008.1.2.1

SCP

SCP/SCU Role

Negotiation

Data Element

Tag

Description

Transaction UID

(0008,1195)

UID to identify this Storage Commitment transaction to respond.

Referenced SOP Sequence

(0008,1199)

A list of SOP Instances to be committed in MUSE. This

corresponding Storage Commitment request.

> Referenced SOP Class UID

(0008,1150)

SOP Class UID of the instance.

> Referenced SOP Inst ance UID

(0008,1155)

SOP Instance UID of the instance.

GE Healthcare

The following table shows the presentation contexts acceptable for this Application Entity for receiving S OP Instances.

Presentation Context Table - Proposed by AE MUSE DICOM Storage Commitment (SCP) for Activity Send Storage

Commitment response to remote AE

Abstract Syntax Transfer Syntax Role

Name UID Name List UID List

Push Model

Implicit VR Little Endian Explicit VR Big Endian

1.2.840.10008.1.2

1.2.840.10008.1.2.2

Extended

Negotiation

Selection

TABLE 18: PROPOSED PRESENTATIO N CO NTEXT FOR STORAGE COMMITMENT REPORT

The MUSE DICOM Storage Commitment (SCP) AE will propose SCU/SCP Role Reversal selection negotiation for the pr esentation contexts of the Storage Commitment PUSH Model SO P Class.

2.3.5.2.1.2.1 SOP Specific DICOM Conformance Statement for the Storage Commitment Push Model SOP Class SCP

The DI COM Storage Commitment (SCP) AE will propose the SCP r ole (via SCP/SCU Role Selection Negotiation) within a Presentation Context for the Storage Commitment Push Model SOP Class. If the destination d oes not a ccept that Role Ne gotiation, the AE will not be able to send Storage Commitment Results using N-Event-Report Requests.

The Storage SCP Application Entity will invoke the N-EVENT-REPORT operation in the established association to send a Storage Commitment response to the remote AE, in response to a previously received Storage Commitment transaction.

The Storage SCP Application Entity can send one or more Storage Commitment responses over a single association. MUSE guarantees storage of the committed SOP Instances.

TABLE 19: DATA ELEMENTS INCLUDED IN SUCCESSFUL STORAGE COMMITMENT REPORT

The Storage SCP Application Entity will use the Event Type ID value 1 to send a Success Storage Commitment response and will include the following data elements in the data part of N-EVENT-REPORT-RQ:

sequence should match the reques ted sequence in the

Page 51

Data Element

Tag

Description

Transaction UID

(0008,1195)

UID used to identify the Storage Commitment transaction to respond to.

Referenced SOP Sequence

(0008,1199)

A list of SOP Instan ces that are successfully committed for long-term archiving in MUSE.

> Referenced SOP Class UID

(0008,1150)

SOP Class UID of the instance.

> Referenced SOP Inst ance UID

(0008,1155)

SOP Instance UID of the instance.

Failed SOP Sequence

(0008,1150)

A list of SOP Instances that are NOT committed for long-term archiving in MUSE.

> Referenced SOP Class UID

(0008,1150)

SOP Class UID of the instance.

> Referenced SOP Inst ance UID

(0008,1155)

SOP Instance UID of the instance.

> Failure Reason

(0008,1197)

Reason that the SOP Instance is not committed for long-term archiving.

GE Healthcare

The Storage SCP Application Entity will use the Event Type ID value 2 to send a “Failure” response and will include the following data elements in the data part of NEVENT-REPORT-RQ:

TABLE 20: DATA ELEMENTS INCLUDED IN FAILED STORAGE COMMITMENT RESPONSE BY STORAGE SCP AE

For any status response received for the N-Event-Report other than success (0000), the DICOM Storage Service (SCP) will record an error in the MUSE logs.

2.3.5.3 Association Initiation Policy

2.3.5.3.1 Real-World Activity - Receive Sto ra g e Co mmitment Request from Remo t e AE

2.3.5.3.1.1 Associated Real-World Activity

The Storage SCP Application Entity is able to accept a Presentation Context for the Storage Commitment – PUSH Model SOP Class either in a dedicated association or in a single association together with Presentation Contexts for Storage SOP Classes. The behavior of the Storage SCP AE with respect to the Storage Commitment service is the same in both cases.

The following re al-world activities are associated with the Receive Storage Commitment Request operation:

• Typically r emote Storage SCU AE would also send a Storage Commitment Request

in the same association in which they perform the C-STORE operation with Storage SCP Application Entity. MUSE does not send Storage Commitment just based on the mere success of having received a SOP Instance. MUSE confirms storage only upon its ability to successfully “Normalize” the SOP Instance.

• Hence, MUSE Storage SCP Application Entity will place a request in the MUSE

Stor ag e C ommi tme nt Queue fo r a response to be sent to the remote Storage SCU AE at a later time.

Page 52

Explicit VR Little Endian

Data Element

Tag

Description

Transaction UID

(0008,1195)

UID to identify this request.

Referenced SOP Sequence

(0008,1199)

A list of SOP Instances to be requested for storage commitment.

> Referenced SOP Class UID

(0008,1150)

SOP Class UID of the instance.

> Referenced SOP Inst ance UID

(0008,1155)

SOP Instance UID of the instance.

GE Healthcare

• The request wo uld include all SOP Instances requested for Storage Commitment, as

well as the calling remote DICOM AE Title.

• For each request, a timer is started when it is added to the Storage Commitment

Queue.

• The Storage SCP Application Entity constantly polls the queue for requests for which

a response can be sent back to the original requester. For this, it relies on MUSE internal software processes to update the request indicating that the SOP Instance could be “Normalized” into MUSE database.

Other components of MUSE will process the Storage Commitment Queue and update the status of

Note:

the requests (pending / completed / failed / time-out). This implementation is beyond the scope of this conformance statement document.

2.3.5.3.1.2 Accepted Presentation Context Table

Presentation Context Table - Accepted by AE DICOM Storage Service (SCP) for Activity Receive Storage Commitment Request from Remote AE

Abstract Syntax Transfer Syntax Role

Name UID Name List UID List

Storage Commitment (Push model)

1.2.840.10008.1.20.1 Implicit VR Little Endian

Explicit VR Big Endian

1.2.840.10008.1.2.1

1.2.840.10008.1.2

1.2.840.10008.1.2.2

SCP None

Extended

Negotiation

2.3.5.3.1.2.1 SOP Specific Conformance Statement for Storage Commitment SOP Class

The MUSE DICOM Storage Service (SCP) Application Entity provides standard conformance to the DICOM Storage Commitment Service as SCP. The Storage SCP Application Entity uses the DIMSE service element N-ACTION to receive a Storage Commitment request.

The Storage SCP Application Entity supports the following data elements in the dataset received in the N-ACTION reque st :

TABLE 21: DATA ELEMENTS SUPPORTED IN STORAGE COMMITMENT REQUEST BY STORAGE SCP AE

The MUSE DICOM Storage Service (SCP) Application Entity will ignore the following data elements if they are included in a Storage Commitment request.

Page 53

Data Element

Tag

Description

Storage Media File-Set ID

(0088,0130)

The DICOM File-Set from all SOP Instances can be retrieved.

Storage Media File-Set UID

(0088,0140)

Referenced Study Component Sequence

(0008,1111)

The Study Component that contains all SO P Instances listed in the referen ced SOP sequence.

GE Healthcare

TABLE 22: DATA ELEMENTS IN STORAGE COMMITMENT REQUEST IGNORED BY STORAGE SCP AE

The MUSE DICOM Storage Service (SCP) Application Entity will accept a Storage Commitment request for referenced SOP Instances already received (known objects) as well as those not yet received at that moment (unknown objects).

If the unknown objects are received and stored successfully at a later time (before the Storage Commitment timer expires), a “Success” response will be sent to the requester.

The MUSE DICOM Storage Service (SCP) AE will return a “Success” Status Code in NACTION-RSP to indicate that the Storage Commitment transaction is received successfully and queued in the MUSE for processing. A Storage Commitment response will be sent to the remote AE via the N-EVENT-REPORT operation.

The MUSE DICOM Storage Service (SCP) AE will return a “Failure” Status Code in NACTION-RSP to indicate that the receipt of the Storage Commitment request failed or the transaction cannot be processed. No Storage Commitment response will be sent to the remote AE.

2.3.5.3.1.3 Presentation Context Acceptance Criterion

The MUSE DICOM Storage Service (SCP) evaluates each Presentation Context independently and accepts any Presentation Context that matches an Abstract Syntax for any real-world activity.

2.3.5.3.1.4 Transfer Syntax Selection Policies

Within each Pr esentation Cont ext the MUSE DICOM Storage Service (SCP) will accept the first proposed transfer syntax that it also supports for that Abstract Syntax.

2.3.6 AE Specification - MUSE DICOM Modality Worklist Find (SCU)

The MUSE Modality Worklist SCU Application Entity supports querying a remote Worklist SCP for items with query keys as described in this Implementation.

SOP Class Name SOP Class UID SCU SCP

Verification SOP Class 1.2.840.10008.1.1 Yes No

This Application Entity provides Standard Conformance to the following SOP Class:

Page 54

GE Healthcare

Modality Worklist Information Model – FIND 1.2.840.10008.5.1.4.31

TABLE 23: SOP CLASS FOR MODALITY WORKLIST SCU AE

2.3.6.1 Association Establishment Policies

Please refer to 2.3.1 for the common association polices that are applicable for all Application Entities. This section describes po licies and/or deviations that are applicable to this Application Entity.

2.3.6.1.1 General

Please refer to 2.3.1.2.1 for the Application Context Name presented by this Application Entity.

Please refer to 2.3.1.1 for the maximum PDU receive size for this Application Entity.

2.3.6.1.2 Number of Associations

MUSE DICOM Modality Worklist Find (SCU) will initiate a maximum of 5 simultaneous associations to remote nodes.

2.3.6.1.3 Asynchronous Nature

Yes No

Please refer to 2.3.1.2.2 for asynchronous association policy for this Application Entity.

2.3.6.1.4 Implementation Identifying Information

Please refer to 2.3.1.2.3 for Implementation Identification information for this Application Entity.

2.3.6.2 Association Initiation Policy

MUSE DICOM Modality Worklist Find (SCU) Application Entity would open a dedicated association with a remote Worklist SCP for querying Worklist items at scheduled intervals.

2.3.6.2.1 Real-World Activity - Query Modality Worklist items from a remote AE

2.3.6.2.1.1 Associated Real-World Activity

2.3.6.2.1.1.1 Description and Sequencing Activities

In order to obtain Modality Worklist items, the MUSE Modality Worklist SCU Application Entity performs the following steps.

Page 55

Explicit VR Little Endian

1.2.840.10008.1.2.1

Description / Module

Tag

Scheduled Procedure Step

Scheduled Procedure Step Sequence

(0040,0100)

>Scheduled Station AE Title

(0040,0001)

Imaging Service Request

Current Patient Location

(0038,0300)

GE Healthcare

1. Once the association is successful, the MUSE Modality Worklist SCU Application

Entity issues DIMSE C-FIND command with the query attributes.

2. MUSE DICOM Modality Wor klist Find (SCU) then kee ps this association open and

waits for the C-FIND-RSP from the remote Worklist SCP.

3. The remote Modality Worklist SCP might provide more than one C-FIND-RSP

object. The association is kept open until a C-FIND-RSP with a Status of “Complete” (0000) is received.

4. As each response comes in, the Modality Wor klist SCU Application Entity parses the

content and creates the corresponding entries in the MUSE database.

2.3.6.2.1.2 Proposed Presenta tion Context Table

The following table shows the Presentation Contexts proposed by DICOM Modality Worklist – Find (SCU) Application Entity to remote AEs:

Presentation Context Table – Proposed by MUSE DICOM Modality Worklist Find (SCU) for Activity Query Modality

Worklist items from a remote AE

Abstract Syntax Transfer Syntax Role

Name UID Name List UID List

Modality Worklist Information Model – FIND

2.3.6.2.1.2.1 SOP Specific DICOM Conformance Statement for the Modality Worklist Information Model - FIND SOP Class

1.2.840.10008.5.1.4.31

TABLE 24: PROPOSED PRESENTATION CONTEXT BY MODALITY WORKLIST SCU AE

The following elements are used by the Modality Worklist SCU Application Entity as query fields to filter the Modality Worklist. The query fields are configurable. A wildcard asterisk character (*) might be used in the query fields to do a broad query.

TABLE 25: FIELDS USED FOR FILTERING MODALITY WORKLIST

Implicit VR Little Endian Explicit VR Big Endian

1.2.840.10008.1.2

1.2.840.10008.1.2.2

SCU None

Extended

Negotiation

At regular intervals of time, which are configurable, the MUSE DICOM Modality Worklist Find (SCU) makes a broad based query to the SCP. The MUSE parses the matching responses, converts them into its internal format, and displays them as orders in its UI.

Page 56

Description / Module

Tag

Scheduled Procedure Step

Scheduled Procedure Step Sequence

(0040,0100)

>Scheduled Station AE Title

(0040,0001)

>Scheduled Procedure Step Start Date

(0040,0002)

>Scheduled Procedure Step Start Time

(0040,0003)

>Modality

(0008,0060)

>Scheduled Performing Physician's Name

(0040,0006)

>Scheduled Procedure Step Description

(0040,0007)

>Scheduled Procedure Step Location

(0040,0011)

Requested Procedure

Requested Procedure ID

(0040,1001)

Requested Procedure Description

(0032,1060)

Requested Procedure Code Sequence

(0032,1064)

>Code Value

(0008,0100)

>Code Meaning

(0008,0104)

Study Instance UID

(0020,000D)

Study Date

(0008,0020)

Study Time

(0008,0030)

Referenced Study Sequence

(0008,1110)

>Referenced SOP Class UID

(0008,1150)

>Referenced SOP Instance UID

(0008,1155)

Requested Procedure Priority

(0040,1003)

Imaging Service Request

Accession Number

(0008,0050)

Requesting Physician

(0032,1032)

Referring Physician's Name

(0008,0090)

Visit Identification

Admission ID

(0038,0010)

Current Patient Location

(0038,0300)

Patient Identification

Patient's Name

(0010,0010)

Patient ID

(0010,0020)

Patient Demographic

Patients Birth Date

(0010,0030)

Patient's Sex

(0010,0040)

Patient's Weight

(0010,1030)

Patient Medical

Medical Alerts

(0010,2000)

GE Healthcare

2.3.6.2.1.2.1.1 Processing Modality Worklist C-Find responses

MUSE Modality SCU expects the following return keys for proper functioning and delivery of full workflow capabilities as described by the product literature. Integrators are advised to check with the remote Modality Worklist SCP conformance statement and confirm that these are available in the response from the SCP.

The Modality Worklist SCU Application Entity will reject the association if it does not find the following keys in the response from the remote Modality Worklist SCP AE it is querying against

TABLE 26: MODALITY WORKLIST RESPONSE KEY MAPPING INFORMATION

Page 57

GE Healthcare

For any response code other than success (0000 ) MUSE will log an error to internal error logs.

2.3.6.2.1.2.1.1.1 Extended Character Sets

The Patient Name (0010, 0010) may be multi-valued to include Ideographic and Phonetic name groups in add ition to an Alphabetic Name. While the Alphabetic Name is always encoded with ISO-IR-8859-1 character sets, the Ideographic and Phonetic Names (other than Kanji names) will be ignored. Refer to page 59 for the list of supported character sets.

2.4 COMMUNICATION PROFILES

2.4.1 Supported Communication Stacks

The DICOM Upper Layer Protocol is supported using TCP /IP as specified in DICOM PS3.8.

2.4.2 Physical Media Support

None of the MUSE Application Entities make assumptions or have limitations pertaining to the physical media over which the TCP/IP stack is implemented.

2.5 EXTENSIONS / SPECIALIZATIONS/ PRIVATIZATIONS

2.5.1 Standard Extended / Specialized / Private SOP Classes

MUSE Application Entities do not implement any private/extended/specialized SOP class.

2.5.2 Private Transfer Syntaxes

No Private Transfer Syntax is supported.

2.6 CONFIGURATION

The exact method for configuring each configurable item is specified in other MUSE documentation. The following sections describe only certain configurable items.

2.6.1 AE Title/Presentation Address Mapping

All configurations below are to be made by qualified GE Field Engineers.

Page 58

GE Healthcare

2.6.2 Configurable Parameters

2.6.2.1 Local AE Title

• AE Titles of the Storage SCP AE for receiving SOP Instances and Storage

Commitment requests.

• AE Titles of the Storage SCU AE for sending SOP Instances.

• AE Titles of the Storage SCU AE for receiving Storage Commitment reports.

• AE Titles of the Modality Worklist SCU AE for querying and receiving DICOM

modality worklists from remote Modality Worklist SCPs.

2.6.2.2 Remote AE Title

• AE Titles of the remote AEs with which MUSE will interact for receiving / sending

SOP Instances, serving Storage Commitment requests and Modality Worklist requests.

• A local mechanism is provided to configure a remote AE Title / Presentation Address

mapping table. This table contains the following data items for each AE entry:

o AE Title o AE Name o TCP/IP addresses o TCP Port Number

If the remote AE is a Storage SCP, an additional configuration to request Storage Commitment can be configured as shown below:

o Request Stor a ge Co mmitment? o Storage Commitment SCP (Can be the same as Storage SCP)

 AE Title  AE Name  TCP/IP addresses  TCP Port Number

Page 59

GE Healthcare

2.6.3 Maximum PDU Size Accepted

The Maximum Length of PD U negotiated b y MUSE is configurabl e up to the maximum value of 65535 bytes.

2.6.4 MUSE DICOM Time-out

The following time-out values are configurable on the MUSE side.

• Association time-out

• Association operation inactivity time-out

• Storage Commitment SCU request association wait-time

• Storage Commitment SCU request stop-time

• Storage Commitment SCP request / response time-out

• Modality Worklist query time-out

2.6.4.1.1 Remote AE Title / Presentation Address Mapping

2.7 SUPPORT OF EXTENDED CHARACTER SETS

MUSE supports following character sets:

• ISO-IR-87 (Japanese Kanji)

• ISO-IR-149 (Korean)

• ISO-IR-192 (Unicode UTF-8)

• ISO 8859 (Latin)

• ISO 10646

In some Application Entities of MUSE, restrictio ns may apply to the extended character sets. See the “Extended Character Sets” subsection found under Association Policies which is located under the scope of each Application Entities for details.

2.8 CODES AND CONTROLLED TERMINOLOGY

The product uses no coded terminology.

2.9 SECURITY PROFILES

The product does not conform to any defined DICOM Security Profiles.

It is assumed that the product is used within a secured environment. It is assumed that a secured environment includes at a minimum:

1. Firewall or router protections to ensure that only approved external hosts have

network access to the product.

2. Firewall or router protections to ensure that the product only has network access to

approved external hosts and services.

Page 60

GE Healthcare

3. Any communications with external hosts and services outside the locally secured

environment use appropriate secure network channels (such as a Virtual Private Network (VPN))

OF DOCUMENT

END

General Electric MUSE v9 DICOM Gateway Pro Conformance Statement_SM_2059568-023_B MUSE v9.0 MUSETM DICOM Gateway Pro Conformance Statement for DICOM v3.0

Specifications and Main Features

Frequently Asked Questions

User Manual

1. INTRODUCTION

1.1 OVERVIEW

1.2 OVERALL DICOM CONFORMANCE STATEMENT DOCUMENT STRUCTURE

1.3 INTENDED AUDIENCE

1.4 SCOPE AND FIELD OF APPLICATION

1.5 IMPORTANT REMARKS

1.6 REFERENCES

1.7 DEFINITIONS

1.8 SYMBOLS AND ABBREVIATIONS

2. NETWORK CONFORMANCE STATEMENT

2.1 INTRODUCTION

2.2 IMPLEMENTATION MODEL

2.2.1 Application Data Flow Diagram

2.2.1.1 Application Data Flow Diagram – Storage SCU AE

2.2.1.2 Application Data Flow Diagram - Storage SCP AE

2.2.1.3 Application Data Flow Diagram - Modality Worklist SCU AE

2.2.2 Functional Definition of AE's

2.2.2.1 Functional Definitio n – MUSE DICOM Storage Service (SCU) AE

2.2.2.2 Functional Definitio n – MUSE DICOM Storage Service (SCP) AE

2.2.2.3 Functional Definitio n - Modality Worklist SCU AE

2.2.3 Sequencing of Real-Wo r ld Ac tivities

2.2.3.1 Sequencing – Storage SCU AE

2.2.3.1.1 Send Storage Commitment Request

2.2.3.2 Sequencing - Storage SCP AE

2.2.3.2.1 Send Storage Commitment Response

2.2.3.3 Sequencing - Modality Worklist SCU AE

2.3 AE SPECIFICATIONS

2.3.1 AE Specification - All Applica t ion Entities

2.3.1.1 Maximum Length of Protocol Data Unit

2.3.1.2 Association Policies

2.3.1.2.1 General

2.3.1.2.2 Asynchronous Nature

2.3.1.2.3 Implementation Identifying Information

2.3.1.2.4 Transfer Syntaxes Supported

2.3.1.3 Timers

2.3.1.3.1 Association Ti mers

2.3.1.3.2 Operation Inactivity Timer

2.3.2 AE Specification – MUSE DICOM Storage Service (SCU)

2.3.2.1 Association Establishment Policies

2.3.2.1.1 General

2.3.2.1.2 Number of Associations

2.3.2.1.3 Asynchronous Nature

2.3.2.1.4 Implementation Identifying Information

2.3.2.2 Association Initiation Policy

2.3.2.2.1 Real-World Activity - Se nd SOP Instance(s) to Remote AE

2.3.2.2.1.1 Associated Real-World Activity

2.3.2.2.1.1.1 Data Retrieval from MUSE Using the Store SCU

2.3.2.2.1.1.2 Sending the Origina l IOD as Received

2.3.2.2.1.2 Proposed Presenta tion Context Table

2.3.2.2.1.2.1 SOP Specific DICOM Conformance Statement for All Storage SOP Classes

2.3.2.2.1.2.1.1 C-STORE-RESPONSE processing

2.3.2.2.1.2.1.2 Extended Character Sets

2.3.2.3 Association Acceptance Policies

2.3.3 AE Specification – MUSE DICOM Storage Service (SCP)

2.3.3.1 Association Establishment Policies

2.3.3.1.1 General

2.3.3.1.2 Number of Associations

2.3.3.1.3 Asynchronous Nature

2.3.3.1.4 Implementation Identifying Information

2.3.3.2 Association Acceptance Policy

2.3.3.2.1 Real-World Activity - Receive SOP Instance from Remote AE

2.3.3.2.1.1 Associated Real-World Activity

2.3.3.2.1.1.1 Description and Sequencing of Activities

2.3.3.2.1.2 Accepted Presentation Context Table

2.3.3.2.1.2.1 SOP Specific Conformance Statement for all Storage SOP Classes

2.3.3.2.1.3 C-STORE Response Status

2.3.3.2.1.4 SOP Instance Storage and Abnormal Association Termination

2.3.3.2.1.4.1 Data Caching

2.3.3.2.1.4.2 SOP Instance Storage Status Conditions in the SCP

2.3.3.2.1.5 Data Elements of Unknown Value R e presentation

2.3.3.2.1.6 Test Type Mapping for Received SOPs

2.3.3.2.1.7 Data Coercion

2.3.3.2.1.8 Presentation Context Acceptance Criterion

2.3.3.2.1.9 Transfer Syntax Selection Policies

2.3.3.3 Supported Uses of SOP Insta nces

2.3.3.3.1 Data Storage