DICOM PS3.2 2019b - Conformance

A.9 Annexes (Current)
Prev | A DICOM Conformance Statement Template (Normative) | Next

## A.9 Annexes

### A.9.1 IOD Contents

#### A.9.1.1 Created SOP Instance(s)

This section specifies each IOD created (including Private IODs). It should specify the Attribute Name, tag, VR, and Value. The Value should specify the range and source (e.g., User input, Modality Worklist, automatically generated, etc.). For content items in templates, the range and source of the concept name and concept values should be specified. Whether the value is always present or not shall be specified.

Recommended abbreviations to be used for the tables are:

VNAP Value Not Always Present (attribute sent zero length if no value is present)

ANAP Attribute Not Always Present

ALWAYS Always Present with a value

EMPTY Attribute is sent without a value

Recommended abbreviations to be used for the source of the data values in the tables are:

USER the attribute value source is from User input

AUTO the attribute value is generated automatically

MWL,MPPS, etc. the attribute value is the same as the value received using a DICOM service such as Modality Worklist, Modality Performed Procedure Step, etc.

CONFIG the attribute value source is a configurable parameter

Specification of a company web address can refer to sample SOP Instances that are available.

Private attributes should be specified.

#### A.9.1.2 Usage of Attributes From Received IODs

Each Application that depends on certain fields to function correctly should specify which ones are required for it to perform its intended function.

#### A.9.1.3 Attribute Mapping

When attributes are used by different SOP Classes, e.g., Modality Worklist, Storage and Modality Performed Procedure Step, this mapping shall be specified. For devices that specify other external protocols, such as HL7, mapping of their fields into the DICOM attributes is not required but highly recommended.

#### A.9.1.4 Coerced/Modified Fields

A SCU might coerce certain Attributes, e.g., the Patient Name. A SCP might provide a different value of an Attribute than was received. These changes shall be specified here. An example is Patient Name, which could be modified using available information from either an internal database or obtained from an Information System/Information Manager. Another example is the generation of a new SOP Instance UID for an existing instance. The conditions influencing such coercion should be specified..

Prev | Up | Next
A.8.3 Application Level Security | Home | A.9.2 Data Dictionary of Private Attributes

DICOM PS3.2 2019b - Conformance