9 Data Types and Structures

9.1 ArrayOf[Type]

A wrapper object representing the encapsulation of an array of a specific type. Used in parameters to and return values from API functions to enable cross-platform compatibility. The wrapper contains a single field, which is an array of the type being stored. The field name is the Type name with the first letter in lowercase instead of uppercase.

Note: This construct was needed to support Microsoft® .NET language bindings even though it looks ugly in Java.

9.2 AvailableData

A DATA STRUCTURE THAT COMMUNICATES WHAT DATA IS AVAILABLE TO THE RECIPIENT. THE DATA IS ORGANIZED IN A HIERARCHICAL FASHION, COMMUNICATING PATIENTS, STUDIES, SERIES, AND FINALLY OBJECTDESCRIPTORS WHICH IDENTIFY AVAILABLE DATA OBJECTS. THE FIELDS IN THE DATA STRUCTURE ARE:

9.2.1 ObjectDescriptor

A data structure with the following fields:

9.2.2 Patient

A data structure that communicates data for a particular patient. The fields in the data structure are:

At least one of objectDescriptors or studies shall be present.

9.2.3 Study

A data structure that communicates data for a particular study. The fields in the data structure are:

9.2.4 Series

A data structure that communicates data for a particular series. The fields in the data structure are:

Note: Most DICOM Composite SOP Instances would be identified by objectDescriptors at the Series level.

9.3 MimeType

A data type whose values are Defined Terms that identify particular MIME content types. The syntax of the string defining a MIME content type is defined in IETF RFC 2045. Top level MIME content types are defined in IETF RFC 2046. MIME content types are drawn from the list managed by the Internet Assigned Numbers Authority (IANA) whose web site is at http://www.iana.org/assignments/media-types/, as described in IETF RFC 2048.

9.4 ModelSetDescriptor

A DATA STRUCTURE RETURNED FROM THE GETASMODELS() METHOD WITH THE FOLLOWING FIELDS:

Note: For example, if the array of UUIDs passed into the getAsModels() call includes 100 CT slices from the same frame of reference (i.e., a volume stack), plus 1 GSPS object, and if the caller requested an Abstract Multi-Dimensional Image model, then the ModelSetDescriptor returned by GetAsModels() would include one UUID in the models array, identifying the CT volume image data created from the 100 CT slices, and one UUID in the failedSourceObjects array, specifying the UUID for the GSPS object.

9.5 ObjectLocator

A DATA STRUCTURE THAT REPRESENTS THE LOCATION FROM WHICH THE RECIPIENT OF A DATA OBJECT CAN RETRIEVE THAT OBJECT. IT CONSISTS OF THE FOLLOWING FIELDS:

9.6 QueryResult

A DATA STRUCTURE THAT HOLDS THE RESULTS FROM AN XPATH QUERY OF A MODEL. IT CONSISTS OF THE FOLLOWING FIELDS:

9.7 QueryResultInfoset

A DATA STRUCTURE THAT HOLDS THE RESULTS FROM AN XPATH QUERY OF A MODEL. IT CONSISTS OF THE FOLLOWING FIELDS:

9.8 Rectangle

A DATA STRUCTURE THAT DEFINES A RECTANGULAR REGION ON A DISPLAY SCREEN. THE FIELDS IN THE DATA STRUCTURE ARE:

that define the location of the top left corner of the region in screen coordinates, and

that specify the extents of the region. Screen coordinates are defined starting from an origin of 0,0 in the upper left corner of the screen, and extend in the positive direction down and to the right.

9.9 State

STATE IS AN ENUMERATED DATA TYPE WITH THE FOLLOWING VALUES:

The interpretation of these enumerated values is defined in section 7.2 States.

9.10 Status

A DATA STRUCTURE WITH THE FOLLOWING FIELDS:

9.10.1 StatusType

An enumerated data type with the following values and definitions:

9.11 UID

A STRING OF PERIOD-SEPARATED DIGITS REPRESENTING A UNIQUE IDENTIFIER (SEE PS3.5), FORMATTED AS DESCRIBED FOR THE UI VR IN PS3.5.

9.12 UUID

A STRING REPRESENTING A UNIVERSALLY UNIQUE IDENTIFIER AS DEFINED IN ITU-T Recommendation X.667, using the hexadecimal representation form.

9.13 XPathNode

A data structure with the following fields, which represents the output from an XPath query of a model, returned in a string-based representation.

9.14 XPathNodeInfoset

A data structure with the following fields, which represents the output from an XPath query of a model returned in a byte array representation.

9.15 XPathNodeType

An enumeration of the types of results that may come back from an XPath query.

Note: This enumeration is compatible with a similar enumeration utilized in the Microsoft .NET framework.

10 Data Exchange Model Conventions

Models that can be used by the model-based DataExchange interface methods are defined in Annex A. These models are defined in the form of XML Schemas written in Relax NG Compact form of DSDL as specified by ISO/IEC 19757.

Note: An implementer may translate the Relax NG Compact form to other forms for use within their implementation as long as the exchanged XML Infosets will validate against the schema specified by the standard. For example, a particular implementation may internally utilize a schema with stronger validation rules (e.g. using Schematron rules as specified in ISO/IEC 19757, or using XSDL with assertion rules) as long as the XML produced for exchange over the interface can be parsed with the schema specified in the standard, and that XML from well-formed DICOM objects produced by the schema specified in the standard can still be utilized by the implementation's internal schema.

Actual instances of the models are XML Infosets. Annex A follows the following conventions in describing models.

Notes: 1. The models are defined via XML schemas to allow the use of commonly available tools to manipulate and navigate the model. For example, an XPath statement can be used to identify portions of interest within the model such as a particular DICOM Attribute and extract it.

2. Some implementations may parse directly from the incoming object, which may not be in XML form, into an internal representation, such as the domain object model (DOM) without ever having converted the object to XML.

Within each model description is a table of XML Elements and XML Attributes used to describe an XML Infoset of that model. These tables utilize the following conventions:

  1. XML Element names (listed in the first column) are in CamelCase, with the first letter capitalized.

  2. XML Attribute names (listed in the first column) are in camelCase with the first letter in lower case.

  3. XML Element and XML Attribute names with a set of “>” characters in front of them are nested within the first preceding XML Element with one fewer “>” characters in front of its name. A nested XML Attribute is associated with the immediately enclosing XML Element.

  4. The entries in the “Optionality” column have the following interpretations:

  5. “R” indicates that the XML Element or XML Attribute is required in all models.

  6. “C” indicates that the XML Element or XML Attribute is required in all models if the condition stated in the Description is met.

  7. “O” indicates that the XML Element or XML Attribute is optional.

  8. If the XML Element or XML Attribute is nested inside another XML Element, and that enclosing XML Element is not present (i.e. it is defined with an Optionality of “O” and is not present in the XML Infoset, or it is defined with an Optionality of “RC” and is not included in the XML Infoset because the condition was not met), then the nested XML Element or XML Attribute shall not be present in the XML Infoset irrespective of its optionality.

  9. The entries in the “Cardinality” column have the following interpretations:

  10. “A” indicates that this is represented as an XML Attribute instead of an XML Element, hence has a cardinality of 1 by definition.

  11. “1” indicates that only a single instance of this XML Element is included inside the immediately enclosing XML Element, or at the top level if this XML Element is not nested inside another XML Element.

  12. “0-n” indicates that zero to n instances of this XML Element are included inside the immediately enclosing XML Element, or at the top level if this XML Element is not nested inside another XML Element.

  13. “1-n” indicates that one to n instances of this XML Element are included inside the immediately enclosing XML Element, or at the top level if this XML Element is not nested inside another XML Element.

  14. Sets of XML Elements and XML Attributes that are often repeated within models may be defined as macros. Macros that may have general applicability are defined in this section. Macros that are unique to a particular model may be defined in the Annex specific that model. When a macro is included within a table, it is as if the contents of the Macro’s table were inserted within the table referencing the macro. Any set of “>” characters in front of the directive to include a Macro in the table are prepended to the XML Element and XML Attribute names listed in the Macro’s table.

10.1 Coded Terminology

Models may make use of coded terminology. The representation of coded terminology in DICOM is described in PS3.3. Specific terminology of interest, organized in Context Groups in PS3.16, can be referenced using the following macro.

Table 10.1-1 Coded Terminology Macro

Name Optionality Cardinality Description
BASIC CODED ENTRY ATTRIBUTES
CodeValue R 1 The particular code value identifying the referenced term or concept. See PS3.3 Section 8.1.
CodingSchemeDesignator R 1 Designates the coding scheme in which the codeValue is defined. See PS3.3 Section 8.2.
CodingSchemeVersion C 1 See PS3.3 Section 8.2. Required if the codingSchemeDesignator is not sufficient to identify the codeValue.
CodeMeaning O 0-1 A brief human readable description of what the coded value means. See PS3.3 Section 8.3.
ENHANCED ENCODING MODE
ContextIdentifier O 0-1 Identifies a Context Group defined within a Mapping Resource from which the values of codeValue and codeMeaning were selected or have been added as a Private Context Group extension See PS3.3 Sections 8.6 and 8.7.
MappingResource C 1 See PS3.3 Section 8.4. Required if the contextIdentifier XML Attribute is present.
ContextGroupVersion C 1 See PS3.3 Section 8.5. Required if the contextIdentifier XML Attribute is present.
ContextGroupExtensionFlag O 0-1 Indicates whether the codeValue/codingScheme/codeMeaning is selected from a private extension of the Context Group identified in the contextIdentifier XML Attribute. (See PS3.3 Section 8.7. Enumerated Values: “Y”, ”N”.
ContextGroupLocalVersion C 1 See PS3.3 Section 8.7.
ContextGroupExtensionCreatorUID C 1 Identifies the person or organization who created an extension to the Context Group. See PS3.3 Section 8.7. Required if the value of contextGroupExtensionFlag is "Y".

10.2 Person Name Components

The Person Name Components follow the definitions given in PS3.5 of the DICOM Standard. The PS3.5 description of the usage of Person Name Components also applies to this macro.

Table 10.2-1 Person Name Components Macro

Name Optionality Cardinality Description
FamilyName O 0-1 The person’s family or last name. See the description of the PN VR in DICOM PS3.5.
GivenName O 0-1 The person’s given or first names. See the description of the PN VR in DICOM PS3.5.
MiddleName O 0-1 The person’s middle names. See the description of the PN VR in DICOM PS3.5.
NamePrefix O 0-1 The person’s name prefix. See the description of the PN VR in DICOM PS3.5.
NameSuffix O 0-1 The person’s name suffix. See the description of the PN VR in DICOM PS3.5.