3.10 Device Independent Pixel Values​

This Part of the Standard makes use of the following terms defined in PS3.3:​

P-Value​ P-Value.​

Profile Connection Space Value​ Profile Connection Space Value (PCS-Value).​ (PCS-Value)​

- Standard -​

3.11 HTTP Definitions​

This Part of the Standard makes use of the following terms defined in [RFC7230]:​

- Standard -​

4 Symbols and Abbreviations​

The following symbols and abbreviations are used in this Part of the DICOM Standard.​

ACR American College of Radiology​

ASCII American Standard Code for Information Interchange​

AE Application Entity​

ANSI American National Standards Institute​

CDS Clinical Decision Support​

CEN TC251 Comité Européen de Normalisation - Technical Committee 251 - Medical Informatics​

Chest CAD Computer-Aided Detection and/or Computer-Aided Diagnosis for chest radiography​

DICOM Digital Imaging and Communications in Medicine​

DIMSE DICOM Message Service Element​

DIMSE-C DICOM Message Service Element-Composite​

DIMSE-N DICOM Message Service Element-Normalized​

HL7 Health Level 7​

IE Information Entity​

IEEE Institute of Electrical and Electronics Engineers​

IOD Information Object Definition​

IS Information System​

ISO International Standards Organization​

JIRA Japan Medical Imaging and Radiological Systems Industries Association​

JPIP JPEG 2000 Interactive Protocol​

MAR Medication Administration Record​

NEMA National Electrical Manufacturers Association​

OSI Open Systems Interconnection​

SCP Service Class Provider​

SCU Service Class User​

SOP Service-Object Pair​

UID Unique Identifier​

- Standard -​

- Standard -​

5 Conventions​

5.1 Entity-Relationship Model​

5.1.1 Entity​

An entity is used in an Entity-Relationship (E-R) model to represent a Real-World Object, class of Real-World Objects, or DICOM​ data representation (such as IOD or Module). An entity is depicted as a box within this Part of the DICOM Standard as shown in​ Figure 5-1.​

Entity Name

Figure 5-1. Entity Convention​

5.1.2 Relationship​

A relationship, which defines how entities are related, is depicted as a diamond within this Standard as shown in Figure 5-2.​

Figure 5-2. Relationship Convention​

The relationship is read from source to destination entity as indicated by the arrows. The a and b show the source and destination​ cardinality of the relationship respectively. The following cardinalities are permitted:​

a.​(a = 1, b = 1) -one source entity is related to one destination entity​

b.​(a = 1, b = 0-n) -one source entity is related to zero or more destination entities​

c.​(a = 1, b = 1-n) -one source entity is related to one or more destination entities​

d.​(a = 1-n, b = 1) -one or more source entities are related to one destination entity​

e.​(a = 1-n, b = 0-n) -one or more source entities are related to zero or more destination entities​

f.​ (a = 1-n, b = 1-n) -one or more source entities are related to one or more destination entities​

In a relationship where (a = 1-n, b = 1-n) the values of the source and destination cardinalities may be different. The value "n" simply​ denotes one or more.​

Note​

DICOM has added the use of arrows to the E-R diagramming conventions often used in other literature. This has been done​ to avoid the possibility of inferring an incorrect relationship that can result from reading a relationship in the reverse order of​ that intended. For example, a relationship "Cat Catches Mouse" could be read "Mouse Catches Cat" if the arrows were not​ present.​

A relationship may be bi-directional (i.e., the relationship is true in both directions). In such a case, the convention used is arrows​ pointing toward both the source and the destination entities.​

5.2 Sequences​

Certain tables in this Part of the DICOM Standard denote a Sequence of Items by using the symbol: '>.'​

- Standard -​

InAnnexA,'>'isusedtoidentifya'SequenceofModules.'NestedSequencesofModulesareidentifiedby'>>'.InAnnexBandAnnex​

C,'>'isusedtoidentifya'SequenceofAttributes'.SeePS3.5forthecompletespecificationofhowSequencesofItemsshallbeencoded.​

Note​

Information Object Definitions (IODs) that include the Sequence of Module construct are often called folders. The use of​ 'Sequences of Attributes' is not limited to 'Folders.'​

5.3 Response Status Values​

Certain tables in this Part of the DICOM Standard denote an implementation specific response status code by using the symbol 'xx'​ or 'xxx' as part of the code.​

Note​

Each 'x' symbol may be replaced by an implementation with a hexadecimal digit in the range from 0 to F.​

5.4 Usage Specification​

The building blocks of SOP Classes are Modules and DIMSE Services. The DIMSE Services associated with a SOP Class may be​ Mandatory (M) or Optional (U). The usage may be different for the SCU and SCP. The usage is specified as a pair of letters: the​ former indicating the SCU usage, the latter indicating the SCP usage.​

5.4.1 Use of DIMSE Services​

The meaning and behavior of the usage specification for DIMSE Services are:​

M/M​The SCU shall support the DIMSE Service but is not required to use it on an Association. The SCP shall support the DIMSE​ Service.​

U/M​The SCU may support and use the DIMSE Service. The SCP shall support the DIMSE Service.​

U/U​The SCU may support and use the DIMSE Service. The SCP may support the DIMSE Service. If the SCP does not support​ the DIMSE Service used by the SCU, it shall return a Failure status.​

5.4.2 Use of Attributes in Normalized Services​

Modules and their usage in Composite IODs are defined in PS3.3. Normalized IODs are also constructed from Modules but usage​ is specified on an Attribute basis in this Part of the DICOM Standard. The following usage specification applies to all Attributes of​ Normalized IODs unless superseded by a usage specification in a particular SOP Class Specification.​

The term ‘receive’ means the following: the value shall be stored; under certain circumstances (e.g. coercion) the value returned may​ have changed.​

5.4.2.1 DIMSE Service N-CREATE, N-SET, N-ACTION​

The following Requirements apply when specifying the use of DIMSE services N-CREATE, N-SET, N-ACTION.​ The convention used in the table below are as follows:​

SCU Behaviour​

Mandatory​ The SCU shall provide the Attribute.​

Optional​ The SCU may or may not provide the Attribute.​

Undefined​ The SCU's usage of the Attribute is undefined.​

SCP Behaviour​

- Standard -​

If the SCU does not provide an Attribute that is Mandatory for the SCU, the SCP shall respond with the error code "Missing Attribute"​ (0120H).​

If the SCU provides a zero-length value for a Mandatory Attribute when zero length is not permitted, the SCP shall respond with the​ error code "Missing Attribute Value" (0121H).​

5.4.2.2 DIMSE Service N-GET, N-EVENT-REPORT​

The following Requirements apply when specifying the use of DIMSE services N-GET, N-EVENT-REPORT.​

The convention used in the table below are as follows:​

SCU Behaviour​

Optional​ The SCU may retrieve the Attribute.​

Undefined​ The SCU's usage of the Attribute is undefined.​

SCP Behaviour​

Mandatory​ The SCP shall support retrieval of the Attribute.​

Optional​ The SCP may or may not support retrieval of the Attribute.​

Undefined​ The SCP’s support of the Attribute is undefined.​

If support of an Attribute by the SCP is optional and the SCP does not support the Attribute and the Attribute is requested by the SCU,​ the SCP shall respond with the error code "Invalid Attribute Value" (0106H) or "Attribute Value out of range" (0116H).​

- Standard -​

5.4.2.3 Other Requirements​

If the SCP usage type designation is modified by a "C" (e.g., 3/1C) the specification stated above shall be modified to include the re-​ quirement that the SCP shall support the Attribute if the specified condition is met.​

For all N-CREATE, N-SET, N-GET, N-DELETE, N-ACTION and N-EVENT-REPORT operations, the SOP Class is conveyed in the​ request primitive in Affected SOP Class UID (0000,0002). The SOP Class UID (0008,0016) Attribute shall not be present in the Data​ Set.​

For N-CREATE operations and N-EVENT-REPORT notifications, the SOP Instance is conveyed in Affected SOP Instance UID​ (0000,1000). The SOP Instance UID (0008,0018) Attribute shall not be present in the Data Set.​

Note​

InsomeServiceClasses,theSOPClassdefinitionmayoverridethegeneralprovisioninPS3.7thatallowstheSOPInstance​ UID to be specified or omitted in the N-CREATE request primitive, and require that the SCU be responsible for specifying​ the SOP Instance UID.​

ForN-SET,N-GET,N-ACTIONandN-DELETEoperations,theSOPInstanceisconveyedinRequestedSOPInstanceUID(0000,1001).​ The SOP Instance UID (0008,0018) Attribute shall not be present in the Data Set.​

- Standard -​

6 DICOM Information Model​

TheDICOMInformationModeldefinesthestructureandorganizationoftheinformationrelatedtothecommunicationofmedicalimages.​ Figure 6-1 shows the relationships between the major structures of the DICOM Information Model.​

6.1 Information Object Definition​

AnInformationObjectDefinition(IOD)isanobject-orientedabstractdatamodelusedtospecifyinformationaboutReal-WorldObjects.​ An IOD provides communicating Application Entities with a common view of the information to be exchanged.​

Service Class

Specification

1 specifies related

n

SOP Class(es)

1

defined as

DIMSE Services

or Media Storage Attributes Services

Figure 6-1. Major Structures of DICOM Information Model​

An IOD does not represent a specific instance of a Real-World Object, but rather a class of Real-World Objects that share the same​ properties.AnIODusedtorepresentasingleclassofReal-WorldObjectsiscalledaNormalizedInformationObject.AnIODthatincludes​ information about related Real-World Objects is called a Composite Information Object.​

6.1.1 Composite IOD​

A Composite IOD is an Information Object Definition that represents parts of several entities in the DICOM Model of the Real-World.​ (see PS3.3.) Such an IOD includes Attributes that are not inherent in the Real-World Object that the IOD represents but rather are​ inherent in related Real-World Objects.​

These related Real-World Objects provide a complete context for the exchanged information. When an instance of a Composite IOD​ is communicated, this entire context is exchanged between Application Entities. Relationships between Composite IOD Instances​ shall be conveyed in this contextual information.​

Note​

1.​Actual communication of IOD Instances is via SOP Instances.​

2.​Whenever Composite SOP Instances are in fact related, some of the contextual information is redundant (i.e., the same​ information about the same Real-World Objects is contained in multiple SOP Instances).​

The Composite IODs are specified in PS3.3.​

6.1.2 Normalized IOD​

A Normalized IOD is an Information Object Definition that generally represents a single entity in the DICOM Model of the Real-World.​

- Standard -​

When an instance of a Normalized IOD is communicated, the context for that instance is not actually exchanged. Instead, the context​ is provided through the use of pointers to related Normalized IOD Instances.​

The Normalized IODs are specified in PS3.3.​

6.2 Attributes​

The Attributes of an IOD describe the properties of a Real-World Object Instance. Related Attributes are grouped into Modules that​ represents a higher level of semantics documented in the Module Specifications found in PS3.3.​

Attributes are encoded as Data Elements using the rules, the Value Representation and the Value Multiplicity concepts specified in​ PS3.5. For specific Data Elements, the Value Representation and Value Multiplicity of Data Elements are specified in the Data Dic-​ tionary in PS3.6.​

6.3 On-Line Communication and Media Storage Services​

For on-line communication the DIMSE Services and Web Services allow a DICOM Application Entity to invoke an operation or notific-​ ation across a network or a point-to-point interface. DIMSE Services are defined in PS3.7 and Web Services are defined in PS3.18.​

Formediastorageinterchange,MediaStorageServicesallowaDICOMApplicationEntitytoinvokemediastoragerelatedoperations.​

Media Storage Services are discussed in PS3.10.​

6.3.1 DIMSE-C Services​

DIMSE-C Services are services applicable only to a Composite IOD. DIMSE-C provides only operation services.​

6.3.2 DIMSE-N Services​

DIMSE-N Services are services applicable only to a Normalized IOD. DIMSE-N provides both operation and notification services.​

6.4 DIMSE Service Group​

A DIMSE Service Group specifies one or more operations/notifications defined in PS3.7 that are applicable to an IOD.​

DIMSE Service Groups are defined in this Part of the DICOM Standard, in the specification of a Service-Object Pair Class.​

6.5 Service-Object Pair (SOP) Class​

The SOP Class definitions in PS3.4 contain the rules and semantics that may restrict the use of the services in the DIMSE Service​ Group or the Attributes of the IOD. PS3.10 and PS3.18 contain the rules and semantics that may restrict the attributes of the IOD or​ the use of the services in the Media Storage Services and the Web Services respectively.​

The selection of SOP Classes is used by Application Entities to establish an agreed set of capabilities to support their interaction for​ SOP Classes based on DIMSE Services. This negotiation is performed at Association establishment time as described in PS3.7. An​ extended negotiation allows Application Entities to further agree on specific options within a SOP Class.​

Note​

1.​TheSOPClassasdefinedintheDICOMInformationModelisequivalentinISO/OSIterminologytotheManagedObject​ Class. Readers familiar with object-oriented terminology will recognize the SOP Class operations (and notifications) as​ comprising the methods of an object class.​

2.​SOP Class Specifications play a central role in defining DICOM conformance. They allow DICOM Application Entities​ to select a well-defined application level subset of this Standard to which they may claim conformance. See PS3.2.​

6.5.1 Normalized and Composite SOP Classes​

DICOM defines two types of SOP Classes, Normalized and Composite. For DIMSE Services, Normalized SOP Classes are defined​ as the union of a Normalized IOD and a set of DIMSE-N Services, while Composite SOP Classes are defined as the union of a​

- Standard -​