# 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.

[pic]

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.

[pic]

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 which 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: '>.'

In Annex A, '>' is used to identify a 'Sequence of Modules.' Nested Sequences of Modules are identified by '>>'. In Annex B and Annex C, '>' is used to identify a 'Sequence of Attributes'. See PS 3.5 for the complete specification of how Sequences of Items shall be encoded.

Note: Information Object Definitions (IODs) which 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' as part of the code.

## 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.

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.

Modules and their usage in Composite IODs are defined in PS 3.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 meaning and behavior of the usage specification for Attributes of Normalized IODs are as follows:

1/1 The SCU shall provide a value for the Attribute. If the SCU does not supply a value, the SCP shall return a Failure status ("Missing Attribute," code 0120H). The SCP shall support the Attribute. The SCP shall not support null values (attribute provided with a zero length and no value) for the Attribute.

3/1 The SCU may retrieve or provide a value for the Attribute. The SCP shall support the Attribute. The SCP shall not support null values (attribute provided with a zero length and no value) for the Attribute.

-/1 The SCU's usage of the Attribute is undefined. The SCP shall support the Attribute. The SCP shall not support null values (attribute provided with a zero length and no value) for the Attribute.

2/2 The SCU shall retrieve or provide a value for the Attribute. The SCU shall always provide the attribute but a null value shall be permitted (attribute provided with a zero length and no value). The SCP shall support the Attribute and permit null values (attribute provided with a zero length and no value) for the Attribute.

3/2 The SCU may retrieve or provide a value for the Attribute. The SCP shall support the Attribute and permit null values (attribute provided with a zero length and no value) for the Attribute.

-/2 The SCU's usage of the Attribute is undefined. The SCP shall support the Attribute and permit null values (attribute provided with a zero length and no value) for the Attribute.

3/3 The SCU may retrieve or provide a value for the Attribute. The SCP may support the Attribute. If the SCP does not support the Attribute and it is requested by the SCU, the SCP shall return either a Failure status (“Invalid Attribute Value”, code 0106H) or a Warning status (“Attribute Value out of Range”, code 0116H). If the SCU provides the Attribute and the SCP does not support the Attribute and returned a failure or warning, the attribute shall be ignored.

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 requirement 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: In some Service Classes, the SOP Class definition may override the general provision in PS 3.7 that allows the SOP Instance 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.

For N-SET, N-GET, N-ACTION and N-DELETE operations, the SOP Instance is conveyed in Requested SOP Instance UID (0000,1001). The SOP Instance UID (0008,0018) Attribute shall not be present in the dataset.