DICOM PS3.21 2024e - Transformations between DICOM and other Representations |
---|
DICOM data types are specified in PS3.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
Additional data type mapping considerations include:
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.
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”.
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.
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.
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.
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.
DICOM Person Name (PN) shall be mapped from [ISO 21090] data type Person Name (PN) as described in Table A.8-3.
[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>
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 |
|||
---|---|---|---|
Measured Value Sequence (0040,A300) > Concept Name Code Sequence (0040,A043) |
|||
Measured Value Sequence (0040,A300) > Numeric Value (0040,A30A) |
CalculationEntity/calculationResultCollection/CalculationResult/@value CalculationEntity/calculationResultCollection/CalculationResult/calculationDataCollection/CalculationData/@value |
||
Measured Value Sequence (0040,A300) > Measurement Units Code Sequence (0040,08EA) |
CalculationEntity/calculationResultCollection/CalculationResult/unitOfMeasure |
||
CalculationEntity/calculationResultCollection/CalculationResult/calculationDataCollection/CalculationData/@value |
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-)
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.
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 |
|||
---|---|---|---|
/ImageAnnotationCollection/imageAnnotations/ImageAnnotation/imageReferenceEntityCollection/ImageReferenceEntity/imageStudy/imageSeries/imageCollection/Image[sopInstanceUid/@root=imageReferenceUid/@root]/sopClassUid/@root |
|||
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.
The AIM version 4.2 model includes an optional AccessionNumber in the imageStudy class used in the imageReferenceEntityCollection. This may be preserved in a DICOM SR instance in the ImageLibrary.
DICOM segmentation references may be mapped as specified in Table A.8-7.
Table A.8-7. DICOM Segmentation references to AIM Path
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. There is optional information in the AIM 4.2 model to identify the Study and Series, but if the Study and Series Instance UIDs are absent, they cannot be assumed to be those of any related images.
The reference to the original image that was segmented or a representative image on which the segmentation may be displayed, which may be present 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").
DICOM PS3.21 2024e - Transformations between DICOM and other Representations |
---|