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:

Annexes A and C of this Part define Standard Templates.

Note: Standard Extended and Private Templates may be defined by implementors 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.

Notes: 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:

TID #Template NameType: (Non-)Extensible Order: (Non-)Significant

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:

TID # Template NameType: (Non-)Extensible Order: (Non-)Significant

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

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

TID # Template NameType: (Non-)Extensible Order: (Non-)Significant

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 folllowing 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 (T-04000, SNM3, “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 (D3-81922, SRT [V1], “Aortic fistula”).

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 PS 3.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 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 in 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 PS 3.3.

Acquisition context and Protocol Context templates have no Relationship field.

Table 6.1.3-1Syntax 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 Concept Name are specified in this 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.

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-1Permitted 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 From i to j occurrences, where i and j are >=1 and j>i.
1-n One or more occurrences

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 occurences 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

Value Set Constraints, if any, are specified in this field as defined or enumerated coded entries, or as baseline or defined context groups.

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 dataset other than within the Content Sequence (0040,A730).

6.1.9.1 NUM Units Constraint

Constraints on units of measurement, if any, 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.

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}

6.2 SPECIAL CONVENTIONS FOR TEMPLATE TABLES

6.2.1 Multiple Value Sets Depending on Different Conditions

When a Content Item may have different value sets, each depending on different conditions, the description of each different case begins in a separate row of the Template Table.

6.2.2 Target Content Items of Relationships

When it is necessary to specify the Target Content Item(s) of a relationship, they are specified in the row(s) immediately following the Source Content Item. The Nesting level of a Target Content Item (or set of Target Content Items specified indirectly via an ‘include Template’ macro) is one greater than the Nesting Level of the corresponding Source Content Item, as indicated by an increase in the number of “>” characters in the nesting level.

When a Content Item may be the Source of multiple relationships having different Relationship Types and/or different Relationship Modes and/or different patterns of Target Content Item(s), the description of each different case begins in a separate row of the Template Table.

When the Source Content Item of a relationship has VM of greater than 1, the specified pattern of Target Content Items applies to all instantiations of the Source Content Item.

Note: For example, if a Template specifies that the VM of a Source Content Item is 1-n and specifies a By-value relationship to two CODE Content Items with particular value set constraints, then each instantiation of the Source Content Item has a By-value relationship to two CODE Content Items with the specified value constraints.

When a Source Content Item that has a Requirement Type of U, UC or MC is not present (is not instantiated), no Target Content Items of that Source Content Item are present, even if one or more of the Target Content Items is designated with a Requirement Type of M or MC.

Note: In otherwords, potential children are not present when there is no parent.

6.2.3 Inclusion of Templates

A Template may specify another Template to be included by specifying “INCLUDE” in the Value Type field and the identifier of the included Template in the Concept Name field. All of the rows of the specified Template are in included in the invoking Template, effectively substituting the specified template for the row where the inclusion is invoked. Whether or not the inclusion is user optional, mandatory or conditional is specified in the Requirement and Condition fields. The number of times the included Template may be repeated is specified in the VM field.

6.2.3.1 Template Parameters

A Template that is included by another Template may include parameters that are replaced by values defined in the invoking Template. Parameters may be used to specify coded concepts or Context Groups in the Concept Name, Condition, or Value Set Constraint fields of a Template.

An included Template that accepts parameters shall be introduced by a table listing those parameters of the form:

Parameter Name Parameter Usage

Parameters are indicated by a name beginning with the character "$".

The invoking Template may specify the value of the parameters in the included Template by name in the Value Set Constraint field of the INCLUDE row. The parameter in the included Template shall be replaced by the specified parameter value. Specification of a parameter value shall be of one of the following forms:

Notation Definition
$parametername = EV or DT (CV, CSD, "CM") The parameter passed to the template is the specified coded term.
$parametername = (CV, CSD, "CM") The parameter passed to the template is the specified coded term, used as a parameter in a Condition field of the included Template.
$parametername = BCID or DCID (CID) CNAME The parameter passed to the template is the Context Group.
$parametername = MemberOf {BCID or DCID (CID) CNAME} The parameter passed to the template is a single coded term from the Context Group in curly braces.

The specification of a parameter value is valid only for the directly included template. Therefore, it needs to be explicitly respecified in templates intermediate between the originally specifying Template and the target Template. The intermediate Template may use the same parameter name as used by the Template it invokes; in such a case, the intermediate Template would invoke the subsidiary Template with a specification in the Value Set Constraint field such as:

$parametername = $parametername

Note: In this case, the left hand instance of $parametername is the name in the subsidiary template, and the right hand instance is the (parameterized) value passed into the current template.

The invoking template is not required to specify all parameters of included templates. If not specified, the value set (term or context group) for that parameter is unconstrained. An unconstrained value in a Condition will cause the condition to fail.

6.2.4 Post-coordinated Codes and Has Concept Modifier Relationship

Though it may not be explicitly shown in a particular Template, the use of any coded Concept Name in any Content Item may be defined in a post-coordinated rather than pre-coordinated manner, unless explicitly forbidden by the IOD or the Template.

Accordingly, any such Content Item may have any number of Target Content Items via a “HAS CONCEPT MOD” relationship, even if not explicitly specifed in a Template. Each Target Content Item of such a relationship may be more complicated than a single Content Item if the IOD permits (i.e. the post-coordinated concept may potentially be defined by a complex sub-tree).

6.2.5 Extension of Templates

An Extensible Template may be extended in an Application generating SOP Instances to include additional Content Items in its definition. Such Content Items shall not duplicate concepts for which an encoding is defined in the Template. I.e., if a method is provided for the encoding of a concept in the Template, that concept shall not be encoded using a different Content Item in an extension to the Template.

Note: There is no requirement that the included additional Content Items in a Template extension be placed at the end of the Template. The additional Content Items may be included at any semantically appropriate location in the Template, regardless of whether the order of Content Items in the Template is significant.

A Non-extensible Template shall not be modified in an Application by the addition of Content Items to its definition.

Notes: The set of Content Items in either an Extensible or a Non-extensible Template may be changed in subsequent editions of the Standard, in accordance with the procedures of the DICOM Standards Committee.

A Non-Extensible Template may include a Template that is Extensible. In invoking such a Template, the content structure of SOP Instances created from the Non-Extensible Template may vary according to the varying content structure allowed by the extension of the included Template.

Note: Specification of such extensible content in a Non-Extensible Template may be desirable if the Template defines, e.g., a fixed top level structure into which a variety of lower level structures may be "plugged".