DICOM PS3.21 2018a - Transformations between DICOM and other Representations

A.8 Overview of Data Types
Prev | A Transformation Between AIM and DICOM SR |

## A.8 Overview of Data Types

DICOM data types are specified in Part 5 of the standard (PS3.5).

The AIM V4 data types are a subset of [ISO 21090], which are in turn based on [V3 DT R1]. The AIM V4 data types used are documented in [AIM v3 v4 changes] and [Extending AIM].

While a complete comparison of DICOM and [ISO 21090] data types, cardinality and optionality is beyond the scope of this mapping guide, some hints are given on topics that are relevant for transforming AIM instances and DICOM SR Measurement Reports.

The AIM V4 model uses the data types as specified in Table A.8-2 from [ISO 21090], of which only a subset are encountered in use cases described by this mapping. In XML encoded AIM instances, the data type is not explicitly encoded, though it is defined in the UML model.

Table A.8-1. ISO 21090 Data Types used in AIM V4

ISO 21090 Data Types | Description
--- | ---
BL | Boolean (two-valued logic). A BL value can be either true or false, or may have a nullFlavor.
CD | Concept Descriptor. A reference to a concept defined in an external code system, terminology or ontology, or an expression in some syntax defined by the referenced code system.
II | Instance Identifier. An identifier that uniquely identifies a thing or object. Instance identifiers are usually defined based on ISO object identifiers.
INT | Integer. No arbitrary limit is imposed on the range of integer numbers.
REAL | Fractional numbers. The typical representation is decimal.
ST | Character string. Shall have at least one character or else have a nullFlavor.
TS | Point in time. A quantity specifying a point on the axis of natural time. Most often represented as a calendar expression.

Additional data type mapping considerations include:

1. Optionality and nullFlavor

   If the original AIM instance does not include values that are required or mandatory in DICOM SR TID 1500, fixed values are specified since empty values are not permitted in DICOM SR TEXT and CODE entries and omitting the Content Item would violate the template constraints. All nullFlavor values are treated as empty, except for numeric values.

2. Character Sets

   DICOM provides information on the interpretation of text data types by specifying a default character set (ISO-IR 6) and "Specific Character Set" (0008,0005) values that are used if the Basic Graphic Set is expanded or replaced. For AIM, the XML declaration attribute "encoding" (overall document) and the attribute "charset" (for ST data type values) may be used to provide information on character sets. See the description of Specific Character Set in Section A.6.1.1.11 “Mapping of DICOM SOP Common Module”.

3. Character strings

   In general, ST text value attributes in AIM XML elements are mapped to DICOM Text Value (0040,A160) of value type TEXT (with a VR of Unlimited Text (UT)) in the SR Content Tree. No maximum length is specified for AIM elements and attributes.

   Some text value attributes in AIM XML elements are mapped to attributes in the DICOM header, and DICOM length limits may apply to character strings such as Long String (LO), e.g., Patient ID.

4. Identifiers

   Unique identifiers in AIM V4 are encoded as the root attribute of an XML element (aim:uniqueIdentifier/​@root), which has an II data type, and are mapped to the DICOM UI VR, which is limited to 64 bytes.

5. Codes

   Codes in AIM V4 are encoded as attributes of the aim:typeCode XML element and are mapped as specified in Table A.8-2 below for the [ISO 21090] code data type (CD). The code and codeSystemName attributes are encountered as attributes of the aim:typeCode XML element, but the displayName is the value attribute of a child element, aim:typeCode/​iso:displayName/​@value. Note that codeSystem (Coding Scheme UID) is usually not sent, even though it is required by [ISO 21090]. DICOM also supports other Attributes for encoding code values that exceed 16 characters in length.

   Table A.8-2. Mapping between DICOM Basic Code Attributes and AIM ISO 21090 Code Data Types (CD)

   DICOM Attribute and VR | AIM Element and Attribute and ISO 21090 Data Type
   --- | ---
   Code Value (0008,0100) | SH | aim:typeCode/​@code | CD.characterstring
   Coding Scheme UID (0008,0x010C) | UI | aim:typeCode/​@codeSystem | CD.characterstring
   Coding Scheme Designator (0008,0102) | SH | aim:typeCode/​@codeSystemName | CD.characterstring
   Coding Scheme Version (0008,0103) | SH | aim:typeCode/​@codeSystemVersion | CD.characterstring
   Code Meaning (0008,0104) | LO | aim:typeCode/​iso:displayName/​@value | CD.ST

6. Date and Time

   - The AIM V4 XML element aim:dateTime/​@value attribute corresponds to the ISO 21090 TS data type, and is mapped to the DICOM DateTime (DT) VR, or the combination of separate Date (DA) and Time (TM) Attributes.

   - DICOM DT matches TS except for the number of decimal places of fractional seconds (6 for DT versus 4 for TS).

   - DICOM DA matches the TS part YYYYMMDD (Y=Year, M=Month, D=Day), except that TS may be missing DD or MMDD.

   - DICOM TM matches the TS part HHMMSS.UUUUUU (H=Hour, M=Minute, S=Second, U=Fractional Second) except for the number of decimal places of fractional seconds (6 for DT versus 4 for TS).

   - If available, the DICOM Timezone Offset From UTC (0008,0201) used for DA or TM data types may be populated using time zone offset values from the ISO 21090 TS value.

   - ISO TS allows for separators; these need to be removed for conversion to DT, DA and TM.

7. Person Names

   - DICOM Person Name (PN) shall be mapped from [ISO 21090] data type Person Name (PN) as described in Table A.8-3.

     Table A.8-3. Mapping between DICOM Person Name (PN) ans ISO 21090 Data Type Person Name (PN)

     DICOM Person Name (PN) | ISO 21090 Data Type: Person Name (PN)
     --- | ---
     <family_name_complex> | Family Part type
     <given_name_complex> | Given Part type
     <middle_name> | Given Part type - order of parts matters
     <name_suffix> | Suffix Part type
     <name_prefix> | Prefix Part type

   - [ISO 21090] PN may contain multiple given names. DICOM PN Middle Name shall be mapped to [ISO 21090] PN Given Name Part type.

     Example A.8-1. Person Name Example

     John Robert Morrison, Ph.D. "Morrison^John Robert^^^Ph.D." [One family name; two given names; no middle name; no prefix; one suffix] can be represented as a [ISO 21090] Person Name (PN) in the following way:

         <name>
            		<given>John</given>
            		<given>Robert</given>
         		<family>Morrison</family>
          		<suffix>Ph.D.</suffix>
         	</name>

   - The following [ISO 21090] PN use codes may be used to represent multi-part DICOM person names: ABC (Alphabetic), IDE (Ideographic), SYL (Phonetic).

     Example A.8-2. HL7 V3 Multi-Part Person Name Example

         <name use="ABC">
            		<family>KIMURA</family>
            		<given>MICHIO</given>
         	</name>
         	<name use='IDE'>
            		<family>木村</family>
            		<given>道男</given>
         	</name>
         	<name use="SYL">
            		<family>きむら</family>
            		<given>みちお</given>
         	</name>

8. Numeric Measurements

   DICOM Numeric Measurement value types shall be mapped from the [ISO 21090] data types as specified in Table A.8-4.

   Table A.8-4. Mapping between DICOM Numeric Measurement Value Types and ISO 21090 Data Types

   DICOM PS3.3, PS3.5 and PS3.16: Numeric Measurement (NUM) Value Type | AIM Path and ISO 21090 Data Type
   --- | ---
   Measured Value Sequence (0040,A300) > Concept Name Code Sequence (0040,A043) | Code Sequence Macro | CalculationEntity/​typeCode[1] | CD
   Measured Value Sequence (0040,A300) > Numeric Value (0040,A30A) | DS | CalculationEntity/​calculationResultCollection/​CalculationResult/​​@value CalculationEntity/​calculationResultCollection/​CalculationResult/​​calculationDataCollection/​CalculationData/​@value | ST
   Measured Value Sequence (0040,A300) > Measurement Units Code Sequence (0040,08EA) | Code Sequence Macro | CalculationEntity/​calculationResultCollection/​CalculationResult/​unitOfMeasure | ST
   Numeric Value Qualifier Code Sequence (0040,A301) | Code Sequence Macro | CalculationEntity/​calculationResultCollection/​CalculationResult/​calculationDataCollection/​CalculationData/​@value | ST

   The [ISO 21090] PQ data type is not used in AIM.

   The Concept Name of the measurement is usually pre-coordinated in a single CalculationEntity/​typeCode entry. If there is more than one CalculationEntity/​typeCode, the first is assumed to be the primary concept and the others may be modifiers that, if recognized as such, may be mapped to method and derivation, or if otherwise recognized and name-value pair of concepts can be constructed can be encoded as generic modifiers, but otherwise have to be ignored.

   The Numeric Value may be found as the single value of a CompactCalculationResult (i.e., value child of CalculationResult) or the first value of an ExtendedCalculationResult (i.e., nested within calculationResultCollection). This can give rise to a difference in representation in a round trip conversion.

   Units of measurement shall be converted from a text string (ST) to a Coded Sequence entry using the UCUM Code Values and "UCUM" as the Coding Scheme Designator (in AIM, CalculationResult/​unitOfMeasure is defined as "A string representation of UCUM unit for the value of the calculation").

   The AIM CalculationData/​@value shall be assumed to be in the US English locale (i.e., periods are used as the decimal point, not commas, etc.).

   The length of the AIM CalculationData/​@value ST is not limited, but the DICOM DS value representation is limited to 16 characters. Values of CalculationData/​@value that are too long shall be truncated or rounded to fit in an implementation-dependent manner.

   The CalculationResult/​dataType (e.g., Double, Integer) is not encoded in the DICOM mapping, since all DICOM SR numeric values are encoded as a Decimal String (DS), so in a round trip from AIM to DICOM and back to AIM will not be recovered (i.e., will always be encoded as Double). For the use cases for this mapping, it is likely that all measurements will be Double anyway.

   DICOM allows the Measured Value Sequence (0040,A300) to be sent zero length (empty) if there is no value. In such cases the Numeric Value Qualifier Code Sequence (0040,A301) may be used in DICOM to send a code indicating why, either because of an invalid floating point result (e.g., (114000, DCM, "Not a number") corresponding to [IEEE 754] NaN), or for more general reasons (e.g., (114006, DCM, "Measurement failure")). See CID 42 “Numeric Value Qualifier”. Table A.8-4 indicates that a non-numeric CalculationData/@value may be mapped to Numeric Value Qualifier Code Sequence (0040,A301). Various possible mappings of AIM string values to a subset of DICOM codes corresponding to [IEEE 754] are defined in Table A.8-5. These are based on the:

   - Java Double.toString(double) definition (see https://docs.oracle.com/javase/8/docs/api/java/lang/Double.html#toString-double-)

   - [XSD Datatypes]

   - [ISO 21090]

   No similar standard C or C++ mapping is known to exist (e.g., for libc dtostr() or sprintf()). Other languages offer some flexibility (e.g., Python supports case insensitive variants of "NaN" and "Infinity", the latter with or without a sign; see http://docs.python.org/3/library/functions.html#float). For JavaScript, see https://tc39.github.io/ecma262/#sec-tostring-applied-to-the-number-type, https://tc39.github.io/ecma262/#sec-parsefloat-string and https://tc39.github.io/ecma262/#sec-number.parsefloat. The table describes a subset of possible values, the mapping may not be exact (e.g., the definitions of NaN may differ), the mapping is ambiguous (since AIM does not define which string source to use), and the mapping of other values is undefined.

   Table A.8-5. Mapping between DICOM Numeric Value Qualifier Code Sequence and AIM ST

   DICOM Code | Java String | XML Schema | ISO 21090 Null Flavor
   --- | --- | --- | ---
   (114000, DCM, "Not a number") | NaN | NaN |
   (114001, DCM, "Negative Infinity") | -Infinity | -INF | NINF
   (114002, DCM, "Positive Infinity") | Infinity | INF | PINF

9. Image and segmentation references

   DICOM image references may be mapped as specified in Table A.8-6.

   Table A.8-6. DICOM Image references to AIM Path

   DICOM PS3.3, PS3.5 and PS3.16: Image Reference (IMAGE) Value Type | AIM Path and ISO 21090 Data Type
   --- | ---
   Referenced SOP Sequence > Referenced SOP Class UID | UI | /Image​Annotation​Collection/​image​Annotations/​Image​Annotation/​imageReferenceEntityCollection/​ImageReferenceEntity/​imageStudy/​imageSeries/​imageCollection/​Image[sopInstanceUid/​@root=​imageReferenceUid/​@root]/​sopClassUid/​@root | II
   Referenced SOP Sequence > Referenced SOP Instance UID | UI | imageReferenceUid/​@root | II
   Referenced SOP Sequence > Referenced Frame Number | IS | referencedFrameNumber/​@value | INT

   An image reference in the AIM tree locally consists of the SOP Instance UID only, without SOP Class, which is described elsewhere in the tree in the imageReferenceEntityCollection (which, similar to the DICOM Current Requested Procedure Evidence Sequence or Pertinent Other Evidence Sequence, also contains the Study and Series level information). Hence the use of the predicate "sopInstanceUid/​@root=$sopInstanceUID" in the path in the table.

   DICOM segmentation references may be mapped as specified in Table A.8-7.

   Table A.8-7. DICOM Segmentation references to AIM Path

   DICOM PS3.3, PS3.5 and PS3.16: Image Reference (IMAGE) Value Type | AIM Path and ISO 21090 Data Type
   --- | ---
   Referenced SOP Sequence > Referenced SOP Class UID | UI | SegmentationEntity/​sopClassUid/​@root | II
   Referenced SOP Sequence > Referenced SOP Instance UID | UI | ​SegmentationEntity/​sopInstanceUid/​@root | II
   Referenced SOP Sequence > Referenced Segment Number | US | SegmentationEntity/​segmentNumber/​@value | INT

   The SOP Class UID is included locally in the AIM tree with the reference, rather than being factored out into the imageReferenceEntityCollection, in which it is not present.

   Ideally, all segmentation references would be included in either Current Requested Procedure Evidence Sequence or Pertinent Other Evidence Sequence as appropriate; however there is insufficient information in the AIM 4.0 model to support this; i.e., the Study and Series Instance UIDs are absent, and cannot safely be assumed to be those of any related images.

   The reference to the original image that was segmented, which may be encoded in SegmentationEntity/​referencedSopInstanceUid/​@root may be encoded in a separate Content Item if supported by the template (e.g., TID 1410, TID 1411) in (121233, DCM, "Source image for segmentation").

Prev | Up |
A.7.2 Target DICOM SR "Measurement Report" (TID 1500) | Home |

DICOM PS3.21 2018a - Transformations between DICOM and other Representations