DICOM PS3.16 2020c - Content Mapping Resource

6 Form of Template Specifications (Current)
Prev |  | Next

# 6 Form of Template Specifications

Templates are patterns that specify the Concept Names, Requirements, Conditions, Value Types, Value Multiplicity, Value Set restrictions, Relationship Types and other attributes of Content Items for a particular application.

An IOD may specify that particular Standard Templates shall be used or may be used to define or constrain the content of a Content Item construct. A Content Item construct includes a coded concept name and one of several types of coded values. Content Item constructs are used in:

- the main Data Set and recursively nested Content Sequences (0040,A730) of the SR Document Content Module

- the Acquisition Context Sequence(0040,0555) of the Acquisition Context Module,

- the Protocol Context Sequence (0040,0440) and Content Item Modifier Sequence (0040,0441) of the Scheduled Procedure Step Module, Image Acquisition Results Module, and others.

- the Specimen Preparation Step Content Item Sequence (0040,0612) of the Specimen Module.

Annexes A and C of this Part define Standard Templates.

### Note

Standard Extended and Private Templates may be defined by implementers of the Standard. The rules for definition of Standard Extended and Private SR Templates are similar to the rules for definition of Standard Extended and Private SOP Classes. One row of a Template definition table corresponds to one row of a Module table.

Each Standard Template is specified by a Template table in this Part. Each Template table specifies exactly one Template, corresponding to a pattern of content within a Content Item construct.

Each Template table identifies whether the order of Content Items is significant or not significant. SOP Instances whose content is based on a Template where the order is significant shall encode the top level Content Items in the order they are specified in the Template, and the subsidiary Content Items under each parent item in the order they are specified, and so on for each Nesting Level. The significance of the order applies only to the Template itself; subsidiary included Templates may have a different order significance.

### Note

Even if a Template specifies that the order is not significant, there may be significance to the order in which Content Items are encoded in a SOP Instance. For example, CONTAINER Content Items with attribute Continuity of Content (0040,A050) value CONTINUOUS encode Content Items in narrative sequence, and procedure logs encode Content Items in time order.

The Content Items from subsidiary Templates may be intermingled if and only if the parent and subsidiary all specify that the order is not significant. This permits later refactoring into reusable Templates.

The range of concepts and the options that are permitted in a family of SR Documents vary inversely with the level of constraint that is applied by the corresponding SR Template. The more narrow the range of concepts and the more restricted the options permitted by a Template, the more predictable the content of the SR Documents will be.

### Note

1. A very specific Template defines a family of SR Documents that are very similar to each other. They have a narrow range of content options (e.g., high level of constraint of Content Item values; use of CODE or NUM with Enumerated Context Groups) and their content is therefore highly predictable. A very general (e.g., permissive or broad) Template defines a family of SR Documents that may differ considerably from one another. They have a broader range of content options (e.g., low level of constraint of Content Item values; use of TEXT and relatively little restriction of Content Item values) and their content is less predictable.

2. The degree of interoperability that may be achieved with a family of SR Documents generated from a Template may be determined intentionally and precisely at a desired level by appropriate Template design to achieve the necessary degree of predictability of SR Document contents.

## 6.1 Template Table Field Definition

SR Templates are described using tables of the following form:

Type:

  (Non-) Extensible

Order:

  (Non-) Significant

Root:

  Yes or No

Table TID <#>. <SR Context Template Name>

| NL | Rel with Parent | VT | Concept Name | VM | Req Type | Condition | Value Set Constraint
--- | --- | --- | --- | --- | --- | --- | --- | ---
1 |  |  |  |  |  |  |  |
2 |  |  |  |  |  |  |  |
3 |  |  |  |  |  |  |  |

Acquisition Context Templates are described using tables of the following form:

Type:

  (Non-) Extensible

Order:

  (Non-) Significant

Table TID <#>. <Acquisition Context Template Name>

| VT | Concept Name | VM | Req Type | Condition | Value Set Constraint
--- | --- | --- | --- | --- | --- | ---
1 |  |  |  |  |  |
2 |  |  |  |  |  |
3 |  |  |  |  |  |

Protocol Context Templates are described using tables of the following form:

Type:

  (Non-) Extensible

Order:

  (Non-) Significant

Table TID <#>. <Protocol Context Template Name>

| NL | VT | Concept Name | VM | Req Type | Condition | Value Set Constraint
--- | --- | --- | --- | --- | --- | --- | ---
1 |  |  |  |  |  |  |
2 |  |  |  |  |  |  |
3 |  |  |  |  |  |  |

The semantics of the fields (columns) of Template tables are defined by subsections of this Section. A row of a Template table specifies either one Content Item or inclusion of another Template that may specify any number of Content Items (see Section 6.2.3 for definition of Included Templates). Each Template table is named by a title, identified by a TID number and further explained by a description such as explanation of Template contents, purpose and use cases.

The following conventions are defined for the form of references to coded concepts, Context Groups and Templates.

Code Meanings are enclosed in quotation marks (for example "cm"). Code Values and Coding Scheme Designators are not enclosed in quotation marks unless a comma occurs in the string.

References to coded concepts take the following form:

- EV or DT (CV, CSD, "CM")

  e.g., an Enumerated Value with only CV, CSD, and CM defined is represented as follows: EV (CV, CSD, "CM"), for example EV (76752008, SCT, "Breast").

- MemberOf { BCID or DCID (CID) CNAME } MemberOf selects one term from the specified context group.

If reference to a specific coding scheme version is required, it takes the following form:

- EV or DT (CV, CSD [CSV], "CM")

  e.g., DT (MA.II.A.5.4A, BI [4.0], "4A - Low suspicion").

References to Context Groups take the following form:

- BCID or DCID (CID) CNAME

  e.g., Defined Context Group 5000 is represented as follows: DCID (5000) Language.

References to Templates take the following form:

- BTID or DTID (TID) TNAME

  e.g., Baseline Template 1000 is represented as follows: BTID (1000) Quotation.

### 6.1.1 Row Number

Each row of a Template Table is denoted by a row number. The first row is numbered 1 and subsequent rows are numbered in ascending order with increments of 1. This number denotes a row for convenient description as well as reference in conditions. The Row Number of a Content Item in a Template may or may not be the same as the ordinal position of the corresponding Sequence Item (representing the Content Item) in a Content Sequence (0040,A730), depending on the number of times the Content Item is repeated.

The Content Item specified in the first row of a Template table may be of any Value Type. Specifically, it is not constrained to be a CONTAINER.

### 6.1.2 Nesting Level (NL)

The nesting level of Content Items is denoted by ">" symbols, one per level of nesting below the initial Source Content Item (of the Template) in a manner similar to the depiction of nested Sequences of Items in Modules Tables in PS3.3. When it is necessary to specify the Target Content Item(s) of a relationship, they are specified in the row(s) immediately following the corresponding Source Content Item. The Nesting Level of a Target Content Item is one greater than the Nesting Level of the corresponding (parent) Source Content Item. The Content Item specified in row 1 of a Template Table is at the top level (i.e., no ">" symbol is ever present in the NL field for the first Content Item in the table).

Acquisition Context Templates have no Nesting Level field. Protocol Context and UPS Processing Parameter Templates allow a single Nesting Level implemented through the Content Item Modifier Sequence (see PS3.3).

### 6.1.3 Relationship With Source Content Item (Parent)

Relationship Type and Relationship Mode (i.e., By-value or By-reference) constraints, if defined, are specified in this field, as described Table 6.1.3-1.

Relationship Type and Mode are specified for each row that specifies a target Content Item.

Relationship Type and Mode may also be specified when another Template is included, either "top-down" or "bottom-up" or both (i.e., in the "INCLUDE Template" row of the calling Template, or in all rows of the included Template, or in both places). There shall be no conflict between the Relationship Type and Mode of a row that includes another Template and the Relationship Type and Mode of the rows of the included Template.

### Note

SR IODs specify Enumerated Values for Relationship Types. If a Relationship Type other than one of the Defined Terms for Relationship Type (0040,A010) is specified in a Private SOP Class, there is a significant risk to interoperability. Documentation accompanying Templates for Private SOP Classes should define any Relationship-type extensions in the manner that the Standard Relationship Types are defined in PS3.3.

Acquisition Context and Protocol Context Templates have no Relationship field.

Table 6.1.3-1. Syntax of Relationship Constraints

Expression | Definition
--- | ---
RTYPE | Relationship Mode is By-value and Relationship Type is RTYPE. For example, "INFERRED FROM".
R-RTYPE | Relationship Mode is By-reference and Relationship Type is RTYPE. For example, "R-INFERRED FROM".

### 6.1.4 Value Type (VT)

The Value Type field specifies the SR Value Type of the Content Item or conveys the word "INCLUDE" to indicate that another Template is to be included (substituted for the row). See Section 6.2.3 for further description of "Included Templates".

### 6.1.5 Concept Name

Any constraints on the Concept Name are specified in the Concept Name field as defined or enumerated coded entries, or as baseline or defined context groups. Alternatively, when the VT field is "INCLUDE", the Concept Name field specifies the Template to be included.

The absence of an entry in the Concept Name field means that any code may be used, from any coding scheme, including codes from private coding schemes.

### 6.1.6 Value Multiplicity (VM)

The VM field indicates the number of times that either a Content Item of the specified pattern or an included Template may appear in this position. Table 6.1.6-1 specifies the values that are permitted in this field.

Table 6.1.6-1. Permitted Values for VM

Expression | Definition
--- | ---
i (where 'i' represents an integer) | Exactly i occurrences, where i>=1. E.g., when i=1 there shall be one occurrence of the Content Item in this position.
i-j (where 'i' and 'j' represent integers) | From i to j occurrences, where i and j are >=1 and j>i.
i-n (where 'i' and 'n' represent integers) | i or more occurrences, where i>=1.

### 6.1.7 Requirement Type

The Requirement Type field specifies the requirements on the presence or absence of the Content Item or included Template.

### Note

There is typically no need to specify Requirement Type separately for SCU and SCP of the Basic SR SOP Classes, because the SCP is required to support the entire content of any SR Document it receives. Therefore, for Basic SR SOP Classes, Requirement Type effectively only applies to the SCU.

The following symbols are used:

M

  Mandatory. Shall be present.

MC

  Mandatory Conditional. Shall be present if the specified condition is satisfied.

U

  User Option. May or may not be present.

UC

  User Option Conditional. May not be present. May be present according to the specified condition.

### Note

There is an interaction between the VM and the Requirement Type with respect to the number of times that a Content Item (or included Template) may actually be present, as follows:

Req Type | VM | Actual number of occurrences in the content tree
--- | --- | ---
M | 1 | 1
M | 1-n | 1 to n
U | 1 | 0 or 1
U | 1-n | 0 to n

### 6.1.8 Condition

The Condition field specifies any conditions upon which presence or absence of the Content Item or its values depends. This field specifies any Concept Name(s) or Values upon which there are dependencies.

References in Condition statements to coded concepts or values, whether to select a Content Item to test or to specify a value to test against, are of the form (CV, CSD, "CM"). As is always the case for coded entries, the matching is performed against CV and CSD, irrespective of the string value of CM.

References may also be made to row numbers (e.g., to specify exclusive OR conditions that span multiple rows of a Template table).

The following abbreviations are used:

XOR

  Exclusive OR. One and only one row shall be selected from mutually-exclusive options.

  ### Note

  For example, if one of rows 1, 2, 3 or 4 may be included, then for row 2, the abbreviation "XOR rows 1, 3, 4" is specified for the condition.

IF

  Shall be present if the condition is TRUE; may be present otherwise.

IFF

  If and only if. Shall be present if the condition is TRUE; shall not be present otherwise.

### 6.1.9 Value Set Constraint

Any constraints on the Value Set for a CODE Content Item are specified in this field as defined or enumerated coded entries, or as baseline or defined context groups.

The absence of an entry in the Value Set Constraint field for a CODE Content Item means that any code may be used, from any coding scheme, including codes from private coding schemes.

The Value Set Constraint column may specify a default value for the Content Item if the Content Item is not present, either as a fixed value, or by reference to another Content Item, or by reference to an Attribute from the Data Set other than within the Content Sequence (0040,A730).

#### 6.1.9.1 NUM Units Constraint

Any constraints on units of measurement are specified in the Value Set Constraint field if and only if the Value Type is NUM. The constraints are specified either as defined or enumerated coded entries, or as baseline or defined context groups.

The absence of any constraint on units of measurement means that any code for units may be used, from any coding scheme, including codes from private coding schemes.

#### 6.1.9.2 CONTAINER Continuation Flag Constraint

The value of the Continuity of Content Flag (0040,A050) may be specified in the Value Set Constraint field if and only if the Value Type is CONTAINER.

### Note

The SR Document Content Module specifies "SEPARATE" and "CONTINUOUS" as the Enumerated Values for Continuity of Content Flag (0040,A050).

#### 6.1.9.3 SCOORD Graphic Type Constraint

Constraints on the value of the Graphic Type(0070,0023) may be specified in the Value Set Constraint field if and only if the Value Type is SCOORD. The constraint may specify a set of allowed values, or a set of disallowed values. For example:

- GRAPHIC TYPE = {POINT}

- GRAPHIC TYPE = {CIRCLE, ELLIPSE}

- GRAPHIC TYPE = not {MULTIPOINT}

Prev |  | Next
5 Conventions | Home | 6.2 Special Conventions for Template Tables

DICOM PS3.16 2020c - Content Mapping Resource