Материал: part03

- 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 an IOD or Module). An entity is depicted as shown in Figure 5.1-1.​

Entity Name

Figure 5.1-1. Entity Convention​

5.1.2 Relationship​

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

Figure 5.1-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.​

- Standard -​

5.2 Sequences​

Certain Tables in this Standard describe Sequences of Items by using the symbol: '>'. The symbol '>' precedes the Attribute (or​ Module) Name of the members of an Item. All marked Attributes (or Modules) belong to the generic description of an Item that may​ be repeated to form a Sequence of Items. This Sequence of Items is nested in the Attribute (or Module) that precedes in the table​ the first member marked with a '>'.​

Note​

The following table describes the "Referenced Series Sequences" Attribute as a Sequence of one or more Items where each​ ItemcontainsthethreeAttributesmarkedbya'>'.TheSequenceofItemsisnestedinsidethevalueoftheReferencedSeries​ Sequence Attribute. The following Attribute (not marked) is not part of the Items of the Sequence.​

This notation may be used to create nested hierarchical structures by using '>>' at the second level of nesting and so on.​

The Type of the Sequence Attribute defines whether the Sequence Attribute itself must be present, and the Attribute Description of​ the Sequence Attribute may define whether and how many Items shall be present in the Sequence. The Types of the Attributes of​ the Data Set included in the Sequence, including any conditionality, are specified within the scope of each Data Set, i.e., for each​ Item present in the Sequence. See PS3.5.​

For describing the number of Items in the Attribute description the following sentences are preferred:​

The encoding of empty Sequence Attributes is described in PS3.5.​

In a number of cases for Normalized IODs, the Data Element Type and Conditions are defined in the appropriate Service definition​ in PS3.4, in other cases in the Attribute description in PS3.3. It is not necessary to specify for any Attribute within a Sequence the​ conditionthatitis"requiredifaSequenceItemispresent",sincethisisalwaysimplicit,whetherornotthereareadditionalrequirements.​

5.3 Triplet Encoding of Structured Data (Retired)​

This section has been retired. See Section 8.​

5.4 Attribute Macros​

Some tables contain references to Attribute Macros. This convention is used in cases where the same Attributes are used in multiple​ tables or multiple placesinone Module. Thereference meansthatthe Attributes of the AttributeMacro shall beincluded inthe Module​ in place of the row that contains the reference to the Attribute Macro.​

- Standard -​

In some cases, the Attribute Macro is used in a Sequence (the VR of the Data Element in which the Attribute is encoded is SQ, see​ PS3.5). When this is done, the reference is preceded by one or more ">" characters. The number of ">" characters indicates the level​ in the Sequence that all of the Attributes in the Attribute Macro occupy.​

There may be specialization of the description of the Attributes in the Attribute Macro. In these cases, this specialization is described​ in the Description column of the Module.​

Following is an example of this convention.​

Table 5.4-1 is an example of a Module table using the Attribute Macro convention.​

Table 5.4-1. Example Module Table​

The contents of the Example Module Table, if it had not been described with the Example Macro would have been as shown in​ Table 5.4-3.​

Table 5.4-3. Example Module Table Without The Use of An Attribute Macro​

5.5 Types and Conditions in Normalized IODs​

When a Normalized Information Object Definition in PS3.3 invokes Modules (e.g., the SOP Common Module) or Attribute Macros​ thatarespecifiedwithDataElementTypes,thosespecifiedDataElementTypesandConditionsdonotapply.Rather,theDataElement​ Types and Conditions have to be specified for each Attribute for both SCU and SCP in the appropriate Service definition in PS3.4.​

5.6 Invocation of Context Groups​

The conventions used for Code Sequences are:​

•​no Baseline Defined​

•​using the Context Group as Baseline Context Group​

•​using the Context Group as Defined Context Group​

See also “Codes and Controlled Terminology Definitions:” in PS3.16.​

- Standard -​