Sup 200 - Transformation of NCI Annotation and Image Markup (AIM) and DICOM SR Measurement Templates DICOM Standards Committee - Working Group 8 - Structured Reporting

1300 N. 17th Street Suite 1752 Rosslyn VA 22209 USA

2017 NEMA Status: Early Draft 2017/02/13 This supplement is prepared pursuant to work item: 2015-12-B

This Supplement defines patterns for transformation of measurement and annotation information for use-cases related to the reporting of quantitaive imaging results. The Annotation and Image Markup (AIM) project defines a UML model and an XML schema for describing the observations that humans or machines make about specific semantic types of information in images: anatomic entities, imaging observations and their characteristics, quantitative imaging features of targets of interest, and other information about targets in images. AIM enables recording qualitative and quantitative features of images. The AIM model captures annotation descriptions, markup (graphical drawing using graphical types consistent with those used in DICOM), computational results of image features and ancillary information related to images into a single common information source. This information is captured using user-defined lexicons and/or well-defined medical lexicons such as RadLex, UMLS, SNOMED CT®, CPT, ICD-9/10, etc. Where it is appropriate a question, also captured as coded term, can be associated with answers. Image annotations in AIM have been used for cancer lesion measurements and ROIs for capturing quantitative imaging features, and it is desirable to harmonize this effort with similar capabilities that exist in DICOM, to allow AIM and DICOM systems to interoperate for these use cases. DICOM PS3.16 defines various templates for different applications. The TID 1500 Measurement Report template describes a generic pattern that is similar to AIM and has been used for the same use cases. This supplement defines a mapping between compatible components of the AIM model and the DICOM SR TID 1500 Measurement Report applicable to quantitative and categorical description of regions of interest in images. Add new DICOM PS3.21 - Transformation of NCI Annotation and Image Markup (AIM) and DICOM SR Measurement Templates as follows: DICOM PS3.21 20xxa - Transformation of NCI Annotation and Image Markup (AIM) and DICOM SR Measurement Templates DICOM Standards Committee 2017 NEMA The information in this publication was considered technically sound by the consensus of persons engaged in the development and approval of the document at the time it was developed. Consensus does not necessarily mean that there is unanimous agreement among every person participating in the development of this document. NEMA standards and guideline publications, of which the document contained herein is one, are developed through a voluntary consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have an interest in the topic covered by this publication. While NEMA administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications. NEMA disclaims liability for any personal injury, property, or other damages of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, application, or reliance on this document. NEMA disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. NEMA does not undertake to guarantee the performance of any individual manufacturer or seller's products or services by virtue of this standard or guide. In publishing and making this document available, NEMA is not undertaking to render professional or other services for or on behalf of any person or entity, nor is NEMA undertaking to perform any duty owed by any person or entity to someone else. Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by this publication may be available from other sources, which the user may wish to consult for additional views or information not covered by this publication. NEMA has no power, nor does it undertake to police or enforce compliance with the contents of this document. NEMA does not certify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance with any health or safety-related information in this document shall not be attributable to NEMA and is solely the responsibility of the certifier or maker of the statement. This DICOM Standard was developed according to the procedures of the DICOM Standards Committee. The DICOM Standard is structured as a multi-part document using the guidelines established in . This part of the DICOM Standard specifies the transformation of compatible components of the NCI Annotation and Image Markup (AIM) and DICOM SR Measurement Templates applicable to quantitative and categorical description of regions of interest in images. The following standards contain provisions that, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below. ISO/IEC Directives, Part 3 ISO/IEC 1989 ISO 21090 ISO 2011 XML W3C 2006/09/29 AIM Model v4 rv48 ISO/IEC 2013/03 caBIG™ AIM Channin, David S Mongkolwat, Pattanasak Kleper, Vladimir Sepukar, Kastubh Rubin, Daniel L 2010/04 23 2 217–225 10.1007/s10278-009-9193-9 AIM Template Builder Mongkolwat, Pattanasak Channin, David S Kleper, Vladimir Rubin, Daniel 2012/07 32 4 1223–1232 10.1148/rg.324115080 AIM Foundation Model Mongkolwat, Pattanasak Kleper, Vladimir Talbot, Skip Rubin, Daniel 2014/12 27 6 692–701 10.1007/s10278-014-9710-3 For the purposes of this Standard the following definitions apply.

The following definitions are commonly used in this Part of the DICOM Standard: Coding Schemes Dictionaries (lexicons) of concepts (terms) with assigned codes and well defined meanings. Content Item A node in the Content Tree of a DICOM SR document, consisting of either a container with a coded Concept Name, or a name-value pair with a coded Concept Name and a Concept Value. Content Tree The tree of Content Items of a DICOM SR document. Context Group A set of coded concepts defined by a Mapping Resource forming a set appropriate to use in a particular context. Context ID (CID) Identifier of a Context Group. Template A pattern that describes the Content Items, Value Types, Relationship Types and Value Sets that may be used in part of a Structured Report content tree, or in other Content Item constructs, such as Acquisition Context or Protocol Context. Analogous to a Module of an Information Object Definition. Template ID (TID) Identifier of a Template.

The following symbols and abbreviations are used in this Part of the Standard. AIM Annotation and Image Markup DICOM Digital Imaging and Communications in Medicine IOD Information Object Definition ISO International Standards Organization NCI National Cancer Institute NEMA National Electrical Manufacturers Association OID Object Identifier (ISO 8824) SR Structured Reporting UCUM Unified Code for Units of Measure UID Unique Identifier XML Extensible Markup Language XSLT Extensible Stylesheet Language Transformations Terms listed in Definitions are capitalized throughout the document.

Constrained NCI AIM objects can be transformed to DICOM SR documents based on DICOM SR . NCI AIM specifies a generic model for encoding structured information about medical images. The AIM model and its XML encoding are version specific. The version transformed in this document is Version 4 [ref AIM v4 model]. Though AIM instances can be generated according to constrained templates [ref. AIM template builder], such templates are too use-case specific to be detailed in the transformation described in this part. Rather, common patterns of use implemented by well known implementations (ref. CC, ref ePAD) have been abstracted and are mapped as described in this document. DICOM SR specifies a generic model for encoding structured information about DICOM instances. DICOM specifies a basic DICOM SR report template for quantitive measurements and categorical statements for single identifiable patient subjects including regions of interest defined by spatial coordinates or segmentations.

The basic use case for the transformation from AIM to DICOM SR is to facilitate the exchange of quantitative and categorical information about DICOM images and regions of interest in DICOM images. AIM and DICOM SR instances both contain references to DICOM images, and both make use use of references to other types DICOM instances such as segmentations. The flow of information between systems that might make use of a conversion between AIM and DICOM SR instances is considered in .

Various different transformation scenarios should be considered: Transformation of a complete constrained AIM instance to a complete DICOM SR Measurement Report. The receiver optionally selects relevant parts of the transformed document for further processing or static or interactive visualization by the user. Transformation of a subset of a constrained AIM instance to a DICOM SR Measurement Report. This subset comprises the relevant information for a specific use-case. Transformation of multiple related constrained AIM instances to a single DICOM SR Measurement Report. The selected related AIM instances comprise the relevant information for a specific use-case. It is beyond the scope of this document to mandate any particular transformation scenario. Rather, transformations of various compatible components of AIM and DICOM SR are described, allowing each of these scenarios to be implemented as appropriate, and enabling a deterministic transformation of the first scenario (complete mapping of an AIM instance to DICOM and vice versa). The use-case that drives the definition of the transformations described in this part is that of taking an existing AIM instance, converting it into DICOM SR, storing it in a DICOM storage system, possibly displaying it with a DICOM SR aware application, and transforming it back into an AIM instance after retrieval from the DICOM storage system. It should be understood that that DICOM SR created by transforming an AIM object will not necessarily be identical in structure and content to a DICOM SR that might have been created de novo by a similar application. For instance, there are various encoding choices that an application implementer may make, especially with respect to the degree of post-coordination of ROI and measurement descriptions that might result in different structures. Conversely, it may not be possible to transform a DICOM SR TID 1500 instance into AIM and retain all of its content, especially with respect to post-coordinated concepts, such as measurement and derivation methods, at least not without pre-coordinating certain post-coordinated structures during the transformation.

DICOM SR documents can be thought of as consisting of a document header and a document body. The header metadata attribute values are grouped into modules such as "Patient", "General Study" in . The SR Document Content Module contains the attributes for the root content item that includes the coded report title. The content tree (structured content) of the document body is contained in the nested Content Sequence Items of that module. "Container" content items are part of the Content Sequence. They are structural elements of the SR document body structure. Content items are DICOM SR document nodes within the content tree that are connected through "by-value" relationships (for Enhanced SR IODs). "By-reference" relationships between content items are not required for the transformations described in this document and are not used by .

The Modules used in a DICOM SR are defined by the Information Object Definition (IOD). A particular DICOM SR template may be encoded using a variety of DICOM SR IODs, depending on the features supported by the template and used by a particular instance. Each SR IOD constrains the Value Types and Relationship Types that are permitted in an instance. The Enhanced SR IOD is sufficient to encode TID 1500 instances unless 3D patient-relative coordinates (rather than 2D image-relative coordinates or segmentations) are used to define regions of interest on images, in which case used of the Comprehensive 3D or Extensible SR IOD would be required. summarizes the modules common to the SR IODs that can encoded the as specified in .

DICOM Enhanced SR IOD Modules

IE	Module	Reference	Usage	Transformation
Patient	Patient		M
	Clinical Trial Subject		U
Study	General Study		M
	Patient Study		U
	Clinical Trial Study		U
Series	SR Document Series		M
	Clinical Trial Series		U
Equipment	General Equipment		M
Document	SR Document General		M
	SR Document Content		M
	SOP Common		M

DICOM SR Header Modules: See also the example . Patient Module The patient module specifies the Attributes of the Patient that describe and identify the Patient who is the subject of a diagnostic Study. This Module contains Attributes of the patient that are needed for diagnostic interpretation of the Image and are common for all studies performed on the patient. Clinical Trial Subject Module The Clinical Trial Subject Module contains attributes that identify a Patient as a clinical trial Subject. General Study Module The General Study Module specifies the Attributes that describe and identify the Study performed upon the Patient. Patient Study Module The Patient Study Module defines the attributes that provide information about the Patient at the time the Study was performed. Clinical Trial Study Module The Clinical Trial Study Module contains attributes that identify a Study in the context of a clinical trial. SR Document Series Module The SR Document Series Module defines the Attributes of the SR Document Series. A Series of SR Documents may contain any number of SR Documents. Clinical Trial Series Module The Clinical Trial Series Module contains attributes that identify a Series in the context of a clinical trials. General Equipment Module The General Equipment Module specifies the Attributes that identify and describe the piece of equipment that produced a Series of Composite Instances. SR Document General Module The SR Document General Module defines the general Attributes of an SR Document Instance. These Attributes identify the SR Document and provide context for the entire document. SOP Common Module The SOP Common Module defines the Attributes that are required for proper functioning and identification of the associated SOP Instances. SR Document Content Module The Attributes in this Module convey the content of an SR Document. It specifies the root content item and the content tree (refer to ).

is the top-level template of the DICOM SR Measurement Report (). It includes sub-templates as shown in . The root content item (coded report title) and the Content Sequence details (structure and contents) are specified by those templates.

The goal of this document is to specify a mapping between constrained AIM v4 instances and DICOM SR documents. The following constraints apply to AIM instances that are mapped to DICOM SR Measurement Reports: : The constrained DICOM SR Basic Diagnostic Imaging Report is restricted to cover exactly one patient subject. : The mapping of "Subject Context, Specimen" () is out of scope for this version of the implementation guide. and reports on animals are not addressed by this implementation guide. The mapping of DICOM SR clinical trial header data (Clinical Trial Subject Module, Clinical Trial Study Module, Clinical Trial Series Module) is out of scope for this version of the implementation guide. The transformation of de-identified SR documents (e.g., for clinical trials and educational purposes) is not addressed in this version of the implementation guide. CDA Release 2 does not address de-identification explicitly (e.g., by definition of flags). De-identified SR documents that have been transformed in accordance with this guide will not be able to have original patient information recovered. The transformation of DICOM Patient Study Module attributes in the document header is out of scope. Pertinent clinical information may be present in the SR content tree and will be mapped to the CDA document body. SR Document General Module, Verifying Observer Sequence (0040,A073): The constrained DICOM SR Basic Diagnostic Imaging Report is restricted to cover exactly one Verifying Observer since CDA R2 only allows for a single Legal Authenticator. SR Document General Module, Participant Sequence (0040,A07A): The constrained DICOM SR Basic Diagnostic Imaging Report is restricted to cover exactly one Data Enterer since CDA R2 only allows for a single dataEnterer. For automated transformation of DICOM SR diagnostic imaging report it is recommended to transform only SR documents where the DICOM Completion Flag (0040,A491) value equals "COMPLETE" to make sure that only SR documents get exported that contain all significant observations (the completeness of the content will be attested or verified by an authorized user). The value of the completion flag can be ignored, if an authorized user confirms that the SR document contains all significant observations. The Completion Flag (0040,A491) cannot be mapped since CDA Release 2 does not specify such flags. Spatial coordinates contained in the content tree of the original DICOM SR document are not mapped because this guideline assumes that Segmentations are used to convey such information.

The hierarchical attributes describing DICOM composite object references are used whenever DICOM composite objects are referenced in the content tree and are also described in the Image Library templates and the Current Requested Procedure Evidence Sequence (0040,A375) or Pertinent Other Evidence Sequence (0040,A385). Information on relevant DICOM objects referenced within the AIM instance are included in the AIM DicomImageReferenceEntity class.

AIM instances are encoded in XML according to a schema generated from the AIM Model , which is defined in UML. is a simplified view rather than the entire model, showing only those UML classes and attributes relevant to the transformations described in this part.

TBD. Elaborate on general AIM structure. Unlike earlier versions, version 4 of AIM makes use of ISO 21090 data types, which are based on HL7 V3 data types. For example, DICOM UIDs are encoded using the Instance Identifier (II) data type.

The transformation is described in one direction, by enumerating the structures in the target (DICOM SR TID 1500) and describing where in the source (AIM v4) the corresponding information may be obtained from. The information is tablated in a manner that can be implemented as an automated "pull" conversion of an AIM instance into a DICOM SR instance, such as might be described using a transformation language such as XSLT. The transformation is intended to be reversible, i.e., by inverting the target and the source. Gaps that exist in the information required in the target to create a compliant object, which need to be filled by information from an out of band source or generated de novo, are highlighted. The tabular representations make use of the following conventions in order to simplify the automatic extraction and use as a formal syntax to drive implementations: DICOM attributes are represented by keywords defined in PS3.6, rather than specifying the data element group and element tags. DICOM attributes that are nested within sequences are shown as a path from the top level data set separated by a ">" symbol. AIM classes, attributes and associations are represented using their XPath representation as encoded in XML instances. DICOM Code Sequence attributes are mapped from AIM CD data type attributes without fully enumerating the corresponding subordinate DICOM attributes and XML elements and attributes. Other DICOM Sequences are listed, without a mapping on the same row, but with the following rows describing the individual DICOM Attributes nested within that Sequence. All source and target paths are fully qualified relative to the root of the instance in order to make the transformation reversible. I.e., it would be possible to describe some transformations using the descendant-or-self axis XSLT operator ("//") if the source were unambiguous but that would not specify the location reversibly as a target. Accordingly, some of the explicit paths are quite long. The requirement type for DICOM is as defined in PS3.3 for Attributes in Modules and Macro, except that if the containing Module in the IOD is not required, e.g., is U rather than M, then a mandatory (Type 1 or 2) Attribute in a user optional (type U) Module is shown as optional (Type 3). The data type and cardinality are specified for both the source and the target, to highlight potential mismatches that may occur during transformation. For nested elements and attributes, the multiplicity is expressed as the combination of the multiplicity along the entire path. E.g., the aim:name attribute has a multiplicity of 1:1 in an aim:Person class but is associated with the aim:ImageAnnotationClass with a multiplicity of 1 -> 0:1, so the multiplicity is indicated as 0:1, not 1:1, since that is the net effect. The XML representation of the AIM UML collapses some associations and classes such they are encoded as a single element, and this is reflected in the mapping paths. E.g., the aim:Person class has an aim:person association from the aim:ImageAnnotationCollection class, so the path to the aim:name attribute is expressed as /ImageAnnotationCollection/person/name, as it appears in the XML instance. Data type transformations are assumed and are not described further unless there is a specific requirement. E.g., conversion from DICOM DA, TM and DT VR Attributes to AIM TS Data Type values is implicit, including extraction/population of the appropriate sub-fields (i.e., only the date portion of a TS is used when creating a DICOM DA value). If value set transformations (as opposed to data type encoding transformations) are defined, they are described. In some cases, explicit value sets are not defined. E.g., aim:Person/sex has no defined explicitly value set but maps to DICOM PatientSex, which does, so if AIM implementations use the DICOM values then the transformation without value mapping will be successful, but not otherwise. When no transformation source is available but a value is required, a Generated Value is indicated, which may be a fixed constant (e.g., a Modality value of "SR"), an indication that an empty (zero length) value or sequence is required, or an indication that a new value of the appropriate VR needs to be generated (e.g., a new UID for a UI VR, a new integer for an IS VR, etc.). The need to generate new values will not produce a deterministic result without a memory of previous conversions. Optional content in the target that has no defined source is not described (e.g., DICOM SeriesDescription in the General Series Module, which, though it would be useful to populate with a generated value, has no correlate in AIM). When the same DICOM Attribute is described in two different Modules, the more specialized (restrictive) use is described in the mapping tables. E.g., InstanceNumber is Type 3 in the SOP Common Module but Type 1 in the SR Document General Module, so it is only described in the latter. Capitalization and punctuation of DICOM keywords and AIM class, attribute and association names is significant.

General Remarks on the mapping of DICOM header module attributes: SR Document General Module Mapping of the observer .... TBD. Attributes of the Predecessor Documents Sequence (0040,A360) and Identical Documents Sequence (0040,A525) are not described in this transformation since they are relevant only in the context of a managed DICOM SR document environment and have no correlate in AIM. Attributes of the Current Requested Procedure Evidence Sequence (0040,A375) and Pertinent Other Evidence Sequence (0040,A385) are described in the transformation and are duplicates of the information described in the Hierarchical SOP Instance Reference Macro used to encode composite instance references, corresponding to the AIM DicomImageReferenceEntity class. Attributes of the Equivalent Document Sequence (0040,A090) are not described in the transformation since they are relevant only in the context of the original DICOM SR document. The name space of the AIM elements is elided, and is implied to be "gme://caCORE.caCORE/4.4/edu.northwestern.radiology.AIM". SOP Common Module Timezone Offset From UTC (0008,0201) shall be considered for attributes of the DICOM SR document that are based on the DA or TM data type (). AIM date and time attributes may or may not contain explicit timezone information that may be extracted to populate Timezone Offset From UTC (0008,0201). The Specific Character Set (0008,0005) is required (Type 1C), if the Basic Graphic Set is expanded or replaced. This is the basis for mapping DICOM character sets to AIM XML Unicode (<?xml version="1.0" encoding="UTF-8"?>) Ambiguities exist for mapping individual characters to Unicode (e.g., for Japanese characters). Resolution of those issues is beyond the scope of this document. Please refer to for further details on data types and character sets. TBD. ???? figure of AIM UML classes that are relevant to header mapping only ????

DICOM Patient Module

DICOM Attribute	VR	VM	Reqt.	Generated Value	AIM Element or Attribute	Data Type	Multiplicity	Comment
PatientName	PN	1	2		Image​Annotation​Collection/​person/​name/​@value	ST	0..1
PatientID	LO	1	2		Image​Annotation​Collection/​person/​id/​@value	ST	0..1
PatientBirthDate	DA	1	2		Image​Annotation​Collection/​person/​birthDate/​@value	TS	0..1
PatientSex	CS	1	2		Image​Annotation​Collection/​person/​sex/​@value	ST	0..1
EthnicGroup	SH	1	3		Image​Annotation​Collection/​person/​ethnicGroup/​@value	ST	0..1

DICOM Clinical Trial Subject Module

DICOM Attribute	VR	VM	Reqt.	Generated Value	AIM Element or Attribute	Data Type	Multiplicity	Comment

AIM does not provide Study information per se (i.e., conceptually an AIM instance may exist independent of a Study, but DICOM requires that SR instances be part of a Study. Accordingly, during transformation from AIM to SR either a new Study may be generated, or the AIM object could be placed in (one of) the Study(ies) referenced by the AIM instance, assuming there are any, which produces a predictable transformation, and is described here.

DICOM General Study Module

DICOM Attribute	VR	VM	Reqt.	Generated Value	AIM Element or Attribute	Data Type	Multiplicity	Comment
StudyInstanceUID	UI	1	1		Image​Annotation​Collection/​imageAnnotations/​ImageAnnotation[1]/​image​Reference​Entity​Collection/​ImageReferenceEntity[1]/​imageStudy[1]/​instanceUid/​@root	II	0..1
StudyDate	UI	1	1		Image​Annotation​Collection/​imageAnnotations/​ImageAnnotation[1]/​image​Reference​Entity​Collection/​ImageReferenceEntity[1]/​imageStudy[1]/​startDate/​@value	TS	0..1
StudyTime	UI	1	1		Image​Annotation​Collection/​imageAnnotations/​ImageAnnotation[1]/​image​Reference​Entity​Collection/​ImageReferenceEntity[1]/​imageStudy[1]/​startTime/​@value	TS	0..1

DICOM Patient Study Module

DICOM Attribute	VR	VM	Reqt.	Generated Value	AIM Element or Attribute	Data Type	Multiplicity	Comment

DICOM Clinical Trial Study Module

DICOM Attribute	VR	VM	Reqt.	Generated Value	AIM Element or Attribute	Data Type	Multiplicity	Comment

DICOM SR Document Series Module

DICOM Attribute	VR	VM	Reqt.	Generated Value	AIM Element or Attribute	Data Type	Multiplicity	Comment
Modality	CS	1	1	"SR"
SeriesInstanceUID	UI	1	1	New
SeriesNumber	IS	1	1	New
ReferencedPerformedProcedureStepSequence	SQ	2	1	Empty

DICOM Clinical Trial Series Module

DICOM Attribute	VR	VM	Reqt.	Generated Value	AIM Element or Attribute	Data Type	Multiplicity	Comment

DICOM General Equipment Module

DICOM Attribute	VR	VM	Reqt.	Generated Value	AIM Element or Attribute	Data Type	Multiplicity	Comment
Manufacturer	LO	1	2		Image​Annotation​Collection/​equipment/​manufacturer/​@value	ST	0..1
ManufacturerModelName	LO	1	3		Image​Annotation​Collection/​equipment/​manufacturerModelName/​@value	ST	0..1
SoftwareVersions	LO	1-n	3		Image​Annotation​Collection/​equipment/​softwareVersion/​@value	ST	0..1

DICOM SR Document General Module

DICOM Attribute	VR	VM	Reqt.	Generated Value	AIM Element or Attribute	Data Type	Multiplicity	Comment
InstanceNumber	IS	1	1	New
CompletionFlag	CS	1	1	"COMPLETE"
VerificationFlag	CS	1	1	"UNVERIFIED"				Sending a value of "VERIFIED" would trigger the need to send the VerifyingObserverSequence, which is not described in this mapping.
ContentDate	DA	1	1		Image​Annotation​Collection/​dateTime/​@value	TS	1..1
ContentTime	TM	1	1		Image​Annotation​Collection/​dateTime/​@value	TS	1..1
Current​Requested​Procedure​Evidence​Sequence	SQ	1	1
Current​Requested​Procedure​Evidence​Sequence>​StudyInstanceUID	UI	1	1		Image​Annotation​Collection/​imageAnnotations/​image​Reference​Entity​Collection/​ImageReferenceEntity/​imageStudy/​instanceUid/​@root	II	1..1
Current​Requested​Procedure​Evidence​Sequence>​ReferencedSeriesSequence	SQ	1	1
Current​Requested​Procedure​Evidence​Sequence>​ReferencedSeriesSequence>​SeriesInstanceUID	UI	1	1		Image​Annotation​Collection/​imageAnnotations/​image​Reference​Entity​Collection/​ImageReferenceEntity/​imageStudy/​imageSeries/​instanceUid/​@root	II	1..1
Current​Requested​Procedure​Evidence​Sequence>​ReferencedSeriesSequence>​ReferencedSOPSequence	SQ	1	1
Current​Requested​Procedure​Evidence​Sequence>​ReferencedSeriesSequence>​ReferencedSOPSequence>​ReferencedSOPClassUID	UI	1	1		Image​Annotation​Collection/​imageAnnotations/​image​Reference​Entity​Collection/​ImageReferenceEntity/​imageStudy/​imageSeries/​imageCollection/​Image/​sopClassUid/​@root	II	1..1
Current​Requested​Procedure​Evidence​Sequence>​ReferencedSeriesSequence>​ReferencedSOPSequence>​ReferencedSOPInstanceUID	UI	1	1		Image​Annotation​Collection/​imageAnnotations/​image​Reference​Entity​Collection/​ImageReferenceEntity/​imageStudy/​imageSeries/​imageCollection/​Image/​sopInstanceUid/​@root	II	1..1

All of the Attributes in the SR Document Content Module are transformed by processing of the DICOM SR Content Tree, and accordingly are not described in the same tabular manner as the "header" Attributes, since the mapping depends on the DICOM SR template structure. The Attributes common to each Content Item of the Content Tree are: ValueType ConceptNameCodeSequence ObservationUID ContentSequence Each child Content Item with a "by-value" relationship with its parent also contains: RelationshipType The additional required Attributes in each Content Item depend on the ValueType, and those relevant to this transformation include: TEXT - Text DATETIME - DateTime DATE - Date TIME - Time PNAME - PersonName UIDREF - UID NUM - MeasuredValueSequence, MeasuredValueSequence>NumericValue, MeasuredValueSequence>MeasurementUnitsCodeSequence CODE - ConceptCodeSequence COMPOSITE - ReferencedSOPSequence, ReferencedSOPSequence>ReferencedSOPClassUID, ReferencedSOPSequence>ReferencedSOPInstanceUID IMAGE - ReferencedSOPSequence, ReferencedSOPSequence>ReferencedSOPClassUID, ReferencedSOPSequence>ReferencedSOPInstanceUID, ReferencedSOPSequence>ReferencedFrameNumber, ReferencedSOPSequence>ReferencedSegmentNumber SCOORD - GraphicData, GraphicType SCOORD3D - ReferencedFrameOfReferenceUID, GraphicData, GraphicType CONTAINER - ContinuityOfContent, ContentTemplateSequence, ContentTemplateSequence>MappingResource, ContentTemplateSequence>TemplateIdentifier

DICOM SOP Common Module

DICOM Attribute	VR	VM	Reqt.	Generated Value	AIM Element or Attribute	Data Type	Multiplicity	Comment
SOPClassUID	UI	1	1	"1.2.840.10008.​5.​1.​4.​1.​1.​88.​22"				The fixed value is the SOP Class UID of the Enhanced SR Storage SOP Class, which is sufficient unless SCOORD3D are used, in which case the Comprehensive 3D SR Storage SOP Class is required, which has a UID of "1.2.840.10008.​5.​1.​4.​1.​1.​88.​34".
SOPInstanceUID	UI	1	1		Image​Annotation​Collection>uniqueIdentifier/​@root	II	1..1
SpecificCharacterSet	CS	1	1	"ISO_IR 192"				The fixed generated value corresponds to the normal UTF-8 specified in the XMLDecl of the XML prolog in the AIM instance. Other values may be used if they are sufficient to describe all the encoded characters in the transformed instance. E.g., it may be omitted entirely if all the characters are US-ASCII.

General Remarks on the mapping of DICOM SR Content Tree:

This section describes a sample AIM v4 instance and the same conent transformed into a DICOM SR TID 1500 instance.

]]>

A compact representation of the semantic content of the transformed DICOM SR tree is shown here: 1: : CONTAINER: (126000,DCM,"Imaging Measurement Report") [SEPARATE] (DCMR,1500) >1.1: HAS CONCEPT MOD: CODE: (121049,DCM,"Language of Content Item and Descendants") = (eng,RFC3066,"English") >>1.1.1: HAS CONCEPT MOD: CODE: (121046,DCM,"Country of Language") = (US,ISO3166_1,"United States") >1.2: HAS OBS CONTEXT: PNAME: (121008,DCM,"Person Observer Name") = "admin" >1.3: HAS OBS CONTEXT: TEXT: (RP-100006,99RPH,"Person Observer's Login Name") = "admin" >1.4: HAS CONCEPT MOD: CODE: (121058,DCM,"Procedure reported") = (24587-8,LN,"brain mri wo+w contr iv") >1.5: CONTAINS: CONTAINER: (111028,DCM,"Image Library") [SEPARATE] >>1.5.1: CONTAINS: CONTAINER: (126200,DCM,"Image Library Group") [SEPARATE] >>>1.5.1.1: CONTAINS: IMAGE: = (1.2.840.10008.5.1.4.1.1.128,2.25.319214308104243787945491694789635628411) >1.6: CONTAINS: CONTAINER: (126010,DCM,"Imaging Measurements") [SEPARATE] >>1.6.1: CONTAINS: CONTAINER: (125007,DCM,"Measurement Group") [SEPARATE] >>>1.6.1.1: HAS OBS CONTEXT: TEXT: (112039,DCM,"Tracking Identifier") = "Lesion1 rwvmtest~sp1~-~sp1~0~sp1~#FFFFFF" >>>1.6.1.2: HAS OBS CONTEXT: UIDREF: (112040,DCM,"Tracking Unique Identifier") = "2.25.56002466128627498886935079903172938041" >>>1.6.1.3: CONTAINS: CODE: (121071,DCM,"Finding") = (SEG,SEG Only,"SEG Only") >>>1.6.1.4: CONTAINS: NUM: (R-404FB,SRT,"Minimum") = 844.98024 >>>1.6.1.5: CONTAINS: NUM: (G-A437,SRT,"Maximum") = 5967.68816 >>>1.6.1.6: CONTAINS: NUM: (R-00317,SRT,"Mean") = 2791.329186593407 >>>1.6.1.7: CONTAINS: NUM: (R-10047,SRT,"Standard Deviation") = 1168.8828952323684 ]]> The AIM sample transformed into SR illustrated at the Attribute encoding level shown in includes information on the SR document body tree depth (column 1: SR Tree Depth), nesting level for nested artifacts such as sequences and sequence items (column 2: Nesting), DICOM attribute names (column 3: Attribute), DICOM tag (column 4: Tag), the DICOM attribute value representation (Column 5: VR as specified in ), the hexadecimal value of value length (column 6: VL (hex)) and the sample document attribute values (column 7: Value).

Transformed SR document encoding at the Attribute level

SR Tree Depth	Nesting	Attribute	Tag	VR	VL (hex)	Value
		File Meta Information Group Length	(0002,0000)	UL	0004	0x000000ba
		File Meta Information Version	(0002,0001)	OB	0002	0x00,0x01
		Media Storage SOP Class UID	(0002,0002)	UI	001e	1.2.840.10008.5.1.4.1.1.88.22
		Media Storage SOP Instance UID	(0002,0003)	UI	002c	2.25.224793923339609181243139195858254344686
		Transfer Syntax UID	(0002,0010)	UI	0014	1.2.840.10008.1.2.1
		Implementation Class UID	(0002,0012)	UI	0016	1.3.6.1.4.1.5962.99.2
		Implementation Version Name	(0002,0013)	SH	0010	PIXELMEDJAVA001
		SOP Class UID	(0008,0016)	UI	001e	1.2.840.10008.5.1.4.1.1.88.22
		SOP Instance UID	(0008,0018)	UI	002c	2.25.224793923339609181243139195858254344686
		Study Date	(0008,0020)	DA	0006	201711
		Content Date	(0008,0023)	DA	0008	20172018
		Study Time	(0008,0030)	TM	0008	07:08:44
		Content Time	(0008,0033)	TM	0002	04
		Accession Number	(0008,0050)	SH	0000
		Modality	(0008,0060)	CS	0002	SR
		Manufacturer	(0008,0070)	LO	0000
		Referring Physician's Name	(0008,0090)	PN	0000
		Manufacturer's Model Name	(0008,1090)	LO	0000
		Referenced Performed Procedure Step Sequence	(0008,1111)	SQ	ffffffff
	%endseq
		Patient's Name	(0010,0010)	PN	0010	CM-1-111-000000
		Patient ID	(0010,0020)	LO	0028	293761767066931586407385203810190772174
		Patient's Birth Date	(0010,0030)	DA	0008	19601000
		Patient's Sex	(0010,0040)	CS	0002	M
		Ethnic Group	(0010,2160)	SH	0000
		Software Version(s)	(0018,1020)	LO	0006	36.00
		Study Instance UID	(0020,000d)	UI	002c	2.25.52186905385055707830834793159643714079
		Study ID	(0020,0010)	SH	0000
		Series Number	(0020,0011)	IS	0004	7291
		Instance Number	(0020,0013)	IS	0002	1
1		Value Type	(0040,a040)	CS	000a	CONTAINER
1		Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
	>	Code Value	(0008,0100)	SH	0006	126000
	>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
	>	Code Meaning	(0008,0104)	LO	001a	Imaging Measurement Report
	%enditem
	%endseq
1		Continuity Of Content	(0040,a050)	CS	0008	SEPARATE
		Performed Procedure Code Sequence	(0040,a372)	SQ	ffffffff
	%endseq
		Current Requested Procedure Evidence Sequence	(0040,a375)	SQ	ffffffff
	%item
	>	Referenced Series Sequence	(0008,1115)	SQ	ffffffff
	%item
	>>	Referenced SOP Sequence	(0008,1199)	SQ	ffffffff
	%item
	>>>	Referenced SOP Class UID	(0008,1150)	UI	001c	1.2.840.10008.5.1.4.1.1.128
	>>>	Referenced SOP Instance UID	(0008,1155)	UI	002c	2.25.319214308104243787945491694789635628411
	%enditem
	%endseq
	>>	Series Instance UID	(0020,000e)	UI	002c	2.25.263500776851326986665835510707132143772
	%enditem
	%endseq
	>	Study Instance UID	(0020,000d)	UI	002c	2.25.52186905385055707830834793159643714079
	%enditem
	%endseq
		Completion Flag	(0040,a491)	CS	0008	COMPLETE
		Verification Flag	(0040,a493)	CS	000a	UNVERIFIED
		Content Template Sequence	(0040,a504)	SQ	ffffffff
	%item
	>	Mapping Resource	(0008,0105)	CS	0004	DCMR
	>	Template Identifier	(0040,db00)	CS	0004	1500
	%enditem
	%endseq
1		Content Sequence	(0040,a730)	SQ	ffffffff
	%item
1.1	>	Relationship Type	(0040,a010)	CS	0010	HAS CONCEPT MOD
1.1	>	Value Type	(0040,a040)	CS	0004	CODE
1.1	>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.1	>>	Code Value	(0008,0100)	SH	0006	121049
1.1	>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.1	>>	Code Meaning	(0008,0104)	LO	0028	Language of Content Item and Descendants
	%enditem
	%endseq
1.1	>	Concept Code Sequence	(0040,a168)	SQ	ffffffff
	%item
1.1	>>	Code Value	(0008,0100)	SH	0004	eng
1.1	>>	Coding Scheme Designator	(0008,0102)	SH	0008	RFC3066
1.1	>>	Code Meaning	(0008,0104)	LO	0008	English
	%enditem
	%endseq
1.1	>	Content Sequence	(0040,a730)	SQ	ffffffff
	%item
1.1.1	>>	Relationship Type	(0040,a010)	CS	0010	HAS CONCEPT MOD
1.1.1	>>	Value Type	(0040,a040)	CS	0004	CODE
1.1.1	>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.1.1	>>>	Code Value	(0008,0100)	SH	0006	121046
1.1.1	>>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.1.1	>>>	Code Meaning	(0008,0104)	LO	0014	Country of Language
	%enditem
	%endseq
1.1.1	>>	Concept Code Sequence	(0040,a168)	SQ	ffffffff
	%item
1.1.1	>>>	Code Value	(0008,0100)	SH	0002	US
1.1.1	>>>	Coding Scheme Designator	(0008,0102)	SH	000a	ISO3166_1
1.1.1	>>>	Code Meaning	(0008,0104)	LO	000e	United States
	%enditem
	%endseq
	%enditem
	%endseq
	%enditem
	%item
1.2	>	Relationship Type	(0040,a010)	CS	0010	HAS OBS CONTEXT
1.2	>	Value Type	(0040,a040)	CS	0006	PNAME
1.2	>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.2	>>	Code Value	(0008,0100)	SH	0006	121008
1.2	>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.2	>>	Code Meaning	(0008,0104)	LO	0014	Person Observer Name
	%enditem
	%endseq
1.2	>	Person Name	(0040,a123)	PN	0006	admin
	%enditem
	%item
1.3	>	Relationship Type	(0040,a010)	CS	0010	HAS OBS CONTEXT
1.3	>	Value Type	(0040,a040)	CS	0004	TEXT
1.3	>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.3	>>	Code Value	(0008,0100)	SH	000a	RP-100006
1.3	>>	Coding Scheme Designator	(0008,0102)	SH	0006	99RPH
1.3	>>	Code Meaning	(0008,0104)	LO	001c	Person Observer's Login Name
	%enditem
	%endseq
1.3	>	Text Value	(0040,a160)	UT	0006	admin
	%enditem
	%item
1.4	>	Relationship Type	(0040,a010)	CS	0010	HAS CONCEPT MOD
1.4	>	Value Type	(0040,a040)	CS	0004	CODE
1.4	>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.4	>>	Code Value	(0008,0100)	SH	0006	121058
1.4	>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.4	>>	Code Meaning	(0008,0104)	LO	0012	Procedure reported
	%enditem
	%endseq
1.4	>	Concept Code Sequence	(0040,a168)	SQ	ffffffff
	%item
1.4	>>	Code Value	(0008,0100)	SH	0008	24587-8
1.4	>>	Coding Scheme Designator	(0008,0102)	SH	0002	LN
1.4	>>	Code Meaning	(0008,0104)	LO	0018	brain mri wo+w contr iv
	%enditem
	%endseq
	%enditem
	%item
1.5	>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.5	>	Value Type	(0040,a040)	CS	000a	CONTAINER
1.5	>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.5	>>	Code Value	(0008,0100)	SH	0006	111028
1.5	>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.5	>>	Code Meaning	(0008,0104)	LO	000e	Image Library
	%enditem
	%endseq
1.5	>	Continuity Of Content	(0040,a050)	CS	0008	SEPARATE
1.5	>	Content Sequence	(0040,a730)	SQ	ffffffff
	%item
1.5.1	>>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.5.1	>>	Value Type	(0040,a040)	CS	000a	CONTAINER
1.5.1	>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.5.1	>>>	Code Value	(0008,0100)	SH	0006	126200
1.5.1	>>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.5.1	>>>	Code Meaning	(0008,0104)	LO	0014	Image Library Group
	%enditem
	%endseq
1.5.1	>>	Continuity Of Content	(0040,a050)	CS	0008	SEPARATE
1.5.1	>>	Content Sequence	(0040,a730)	SQ	ffffffff
	%item
1.5.1.1	>>>	Referenced SOP Sequence	(0008,1199)	SQ	ffffffff
	%item
1.5.1.1	>>>>	Referenced SOP Class UID	(0008,1150)	UI	001c	1.2.840.10008.5.1.4.1.1.128
1.5.1.1	>>>>	Referenced SOP Instance UID	(0008,1155)	UI	002c	2.25.319214308104243787945491694789635628411
	%enditem
	%endseq
1.5.1.1	>>>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.5.1.1	>>>	Value Type	(0040,a040)	CS	0006	IMAGE
	%enditem
	%endseq
	%enditem
	%endseq
	%enditem
	%item
1.6	>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.6	>	Value Type	(0040,a040)	CS	000a	CONTAINER
1.6	>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.6	>>	Code Value	(0008,0100)	SH	0006	126010
1.6	>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.6	>>	Code Meaning	(0008,0104)	LO	0014	Imaging Measurements
	%enditem
	%endseq
1.6	>	Continuity Of Content	(0040,a050)	CS	0008	SEPARATE
1.6	>	Content Sequence	(0040,a730)	SQ	ffffffff
	%item
1.6.1	>>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.6.1	>>	Value Type	(0040,a040)	CS	000a	CONTAINER
1.6.1	>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.6.1	>>>	Code Value	(0008,0100)	SH	0006	125007
1.6.1	>>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.6.1	>>>	Code Meaning	(0008,0104)	LO	0012	Measurement Group
	%enditem
	%endseq
1.6.1	>>	Continuity Of Content	(0040,a050)	CS	0008	SEPARATE
1.6.1	>>	Content Sequence	(0040,a730)	SQ	ffffffff
	%item
1.6.1.1	>>>	Relationship Type	(0040,a010)	CS	0010	HAS OBS CONTEXT
1.6.1.1	>>>	Value Type	(0040,a040)	CS	0004	TEXT
1.6.1.1	>>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.6.1.1	>>>>	Code Value	(0008,0100)	SH	0006	112039
1.6.1.1	>>>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.6.1.1	>>>>	Code Meaning	(0008,0104)	LO	0014	Tracking Identifier
	%enditem
	%endseq
1.6.1.1	>>>	Text Value	(0040,a160)	UT	0028	Lesion1 rwvmtest~sp1~-~sp1~0~sp1~#FFFFFF
	%enditem
	%item
1.6.1.2	>>>	Relationship Type	(0040,a010)	CS	0010	HAS OBS CONTEXT
1.6.1.2	>>>	Value Type	(0040,a040)	CS	0006	UIDREF
1.6.1.2	>>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.6.1.2	>>>>	Code Value	(0008,0100)	SH	0006	112040
1.6.1.2	>>>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.6.1.2	>>>>	Code Meaning	(0008,0104)	LO	001a	Tracking Unique Identifier
	%enditem
	%endseq
1.6.1.2	>>>	UID	(0040,a124)	UI	002c	2.25.56002466128627498886935079903172938041
	%enditem
	%item
1.6.1.3	>>>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.6.1.3	>>>	Value Type	(0040,a040)	CS	0004	CODE
1.6.1.3	>>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.6.1.3	>>>>	Code Value	(0008,0100)	SH	0006	121071
1.6.1.3	>>>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.6.1.3	>>>>	Code Meaning	(0008,0104)	LO	0008	Finding
	%enditem
	%endseq
1.6.1.3	>>>	Concept Code Sequence	(0040,a168)	SQ	ffffffff
	%item
1.6.1.3	>>>>	Code Value	(0008,0100)	SH	0004	SEG
1.6.1.3	>>>>	Coding Scheme Designator	(0008,0102)	SH	0008	SEG Only
1.6.1.3	>>>>	Code Meaning	(0008,0104)	LO	0008	SEG Only
	%enditem
	%endseq
	%enditem
	%item
1.6.1.4	>>>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.6.1.4	>>>	Value Type	(0040,a040)	CS	0004	NUM
1.6.1.4	>>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.6.1.4	>>>>	Code Value	(0008,0100)	SH	0008	R-404FB
1.6.1.4	>>>>	Coding Scheme Designator	(0008,0102)	SH	0004	SRT
1.6.1.4	>>>>	Code Meaning	(0008,0104)	LO	0008	Minimum
	%enditem
	%endseq
1.6.1.4	>>>	Measured Value Sequence	(0040,a300)	SQ	ffffffff
	%item
1.6.1.4	>>>>	Measurement Units Code Sequence	(0040,08ea)	SQ	ffffffff
	%item
1.6.1.4	>>>>>	Code Value	(0008,0100)	SH	0006	{SUV}
1.6.1.4	>>>>>	Coding Scheme Designator	(0008,0102)	SH	0004	UCUM
1.6.1.4	>>>>>	Code Meaning	(0008,0104)	LO	0004	SUV
	%enditem
	%endseq
1.6.1.4	>>>>	Numeric Value	(0040,a30a)	DS	000a	844.98024
	%enditem
	%endseq
	%enditem
	%item
1.6.1.5	>>>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.6.1.5	>>>	Value Type	(0040,a040)	CS	0004	NUM
1.6.1.5	>>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.6.1.5	>>>>	Code Value	(0008,0100)	SH	0006	G-A437
1.6.1.5	>>>>	Coding Scheme Designator	(0008,0102)	SH	0004	SRT
1.6.1.5	>>>>	Code Meaning	(0008,0104)	LO	0008	Maximum
	%enditem
	%endseq
1.6.1.5	>>>	Measured Value Sequence	(0040,a300)	SQ	ffffffff
	%item
1.6.1.5	>>>>	Measurement Units Code Sequence	(0040,08ea)	SQ	ffffffff
	%item
1.6.1.5	>>>>>	Code Value	(0008,0100)	SH	0006	{SUV}
1.6.1.5	>>>>>	Coding Scheme Designator	(0008,0102)	SH	0004	UCUM
1.6.1.5	>>>>>	Code Meaning	(0008,0104)	LO	0004	SUV
	%enditem
	%endseq
1.6.1.5	>>>>	Numeric Value	(0040,a30a)	DS	000a	5967.68816
	%enditem
	%endseq
	%enditem
	%item
1.6.1.6	>>>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.6.1.6	>>>	Value Type	(0040,a040)	CS	0004	NUM
1.6.1.6	>>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.6.1.6	>>>>	Code Value	(0008,0100)	SH	0008	R-00317
1.6.1.6	>>>>	Coding Scheme Designator	(0008,0102)	SH	0004	SRT
1.6.1.6	>>>>	Code Meaning	(0008,0104)	LO	0004	Mean
	%enditem
	%endseq
1.6.1.6	>>>	Measured Value Sequence	(0040,a300)	SQ	ffffffff
	%item
1.6.1.6	>>>>	Measurement Units Code Sequence	(0040,08ea)	SQ	ffffffff
	%item
1.6.1.6	>>>>>	Code Value	(0008,0100)	SH	0006	{SUV}
1.6.1.6	>>>>>	Coding Scheme Designator	(0008,0102)	SH	0004	UCUM
1.6.1.6	>>>>>	Code Meaning	(0008,0104)	LO	0004	SUV
	%enditem
	%endseq
1.6.1.6	>>>>	Numeric Value	(0040,a30a)	DS	0012	2791.329186593407
	%enditem
	%endseq
	%enditem
	%item
1.6.1.7	>>>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.6.1.7	>>>	Value Type	(0040,a040)	CS	0004	NUM
1.6.1.7	>>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
	%item
1.6.1.7	>>>>	Code Value	(0008,0100)	SH	0008	R-10047
1.6.1.7	>>>>	Coding Scheme Designator	(0008,0102)	SH	0004	SRT
1.6.1.7	>>>>	Code Meaning	(0008,0104)	LO	0012	Standard Deviation
	%enditem
	%endseq
1.6.1.7	>>>	Measured Value Sequence	(0040,a300)	SQ	ffffffff
	%item
1.6.1.7	>>>>	Measurement Units Code Sequence	(0040,08ea)	SQ	ffffffff
	%item
1.6.1.7	>>>>>	Code Value	(0008,0100)	SH	0006	{SUV}
1.6.1.7	>>>>>	Coding Scheme Designator	(0008,0102)	SH	0004	UCUM
1.6.1.7	>>>>>	Code Meaning	(0008,0104)	LO	0004	SUV
	%enditem
	%endseq
1.6.1.7	>>>>	Numeric Value	(0040,a30a)	DS	0012	1168.8828952323684
	%enditem
	%endseq
	%enditem
	%endseq
	%enditem
	%endseq
	%enditem
	%endseq

DICOM data types are specified in Part 5 of the standard (), AIM v4 is based on . While a complete comparison of DICOM and ISO data types, cardinality and optionality is beyond the scope of this implementation guide, some hints are given on topics that are relevant for transforming AIM instance to DICOM SR Measurement Reports. Optionality If the original DICOM SR document does not include values for optional attributes that are required or mandatory in CDA R2, the null flavor value "NI" (No Information) can be used as the default for those attributes unless specific reasons for missing values are known. 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 ED and ST data type values) may be used to provide information on character sets. Character strings Text Value (0040,A160) of value type TEXT (data type: Unlimited Text (UT)) shall be mapped to HL7 V3 data type ED (text (TXT) representation; media type = "text/plain") to populate CDA R2 text observation entries and section text. The ED text representation is identical to HL7 V3 data type ST (Character String). Character strings that are used for DICOM attributes such as Study Description (Long String, LO) are mapped to ST. Maximum length is not specified for HL7 V3 data types ED and ST. DICOM character strings such as Long String (LO, e.g., Manufacturer's Model Name (0008,1090)) and Unlimited Text (UT, e.g., Observer's Model Name within ) can be mapped to the character string part of HL7 V3 data type SC (Character String with Code). SC code components are optional. Identifiers DICOM UI (data type: Unique Identifier, UID) is limited to 64 bytes. UIDs shall be mapped to the root portion of HL7 V3 Instance Identifiers (II). DICOM Placer Number, Filler Number, Accession Number (Unlimited Text, UT) and Patient ID (Long String, LO) are usually non-globally unique identifiers. However, a globally unique root is mandatory for the HL7 V3 Instance Identifier (II) data type. Order number, placer number, accession number and patient id may be used as an extension to the II root representing the ID assigning authority. If information on Issuer of Patient ID is available from the DICOM SR document (Patient Module), Universal Entity ID (0040,0032) of the Issuer of Patient ID Qualifiers Sequence (0010,0024) shall be mapped to PatientRole.id II root and Patient ID (0010,0020) to PatientRole.id II extension. Otherwise a globally unique identifier (ISO Object Identifier) may be generated for the PatientRole.id II root portion. If available Issuer of Patient ID (0010,0021) shall be mapped to PatientRole.id assigningAuthorityName.). Codes Basic code attributes are mapped as specified in below for HL7 V3 code data types (CV, CS, CE and CD).

Basic Code Attributes Mapping to HL7 V3 Code Data Types (CV, CS, CE and CD)

DICOM , and		HL7 V3 Data Types R1
Code Value (0008,0100)	SH	code	ST
Coding Scheme UID ()	UID	codeSystem	UID
Coding Scheme Designator (0008,0102)	SH	codeSystemName	ST
Coding Scheme Version (0008,0103)	SH	codeSystemVersion	ST
Code Meaning (0008,0104)	LO	displayName	ST

The actual encoding for CV, CE and CD will be the same. The difference are optional fields that are not present in the DICOM report. For document titles the Code Meaning value may be mapped to the CDA title string (ST). For coded DICOM SR person identifiers the Code Value shall be mapped to the root portion of the HL7 V3 instance identifier (II). Patient's Sex (DICOM coded string: CS) shall be mapped to the appropriate administrativeGenderCode attribute code (HL7 V3: CE). Ethnic Group (DICOM short string: SH) shall be mapped to the appropriate ethnicGroupCode attribute code (HL7 V3: CE). If this report was generated automatically, Station Name (DICOM short string: SH) shall be mapped to AuthoringDevice.code (CE) original text. Basic code values of the AuthoringDevice.code shall be set to null flavor value "OTH" (other) because no specific codes are available. Units of measurement in observations shall be transcoded to UCUM. Date and Time DICOM data types DateTime (DT), Date (DA) and Time (TM) shall be mapped to HL7 V3 data type Point in Time (TS). DICOM DT matches TS except for the number of decimal places of fractional seconds (6 versus 4 for TS). DICOM DA matches the TS part YYYYMMDD (Y=Year, M=Month, D=Day). DICOM DT 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 versus 4 for TS). If available, DICOM Timezone Offset From UTC (0008,0201) values shall be used for DA or TM data types to populate time zone offset values of HL7 V3 data type TS. Person and Organization Names DICOM Person Name (PN) shall be mapped to HL7 V3 data type Person Name (PN) as described in .

DICOM Person Name (PN) Mapping to HL7 V3 Data Type Person Name (PN)

DICOM Person Name (PN)	HL7 V3 Data Types R1: 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

HL7 V3 PN may contain multiple given names. DICOM PN Middle Name shall be mapped to HL7 V3 PN Given Name Part type. 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 HL7 V3 Person Name (PN) in the following way: John Robert Morrison Ph.D. ]]> The following HL7V3 PN use codes may be used to represent multi-part DICOM person names: ABC (Alphabetic), IDE (Ideographic), SYL (Phonetic). KIMURA MICHIO 木村 道男 きむら みちお ]]> DICOM character strings representing organization names shall be mapped to HL7 V3 data type Organization Name (ON). ON may be populated with free text. Addresses DICOM address character strings (e.g., Short Text (ST)) shall be mapped to HL7 V3 data type Postal Address (AD). AD may be populated with free text. Numeric Measurements DICOM Numeric Measurement value types shall be mapped to HL7 V3 Physical Quantity data types as specified in .

DICOM Numeric Measurement Value Types Mapped to HL7 V3 Physical Quantity Data Types

DICOM , and : Numeric Measurement (NUM) Value Type		HL7 V3 Data Types R1: Physical Quantity (PQ)
Numeric Value (0040,A30A)	DS	value	REAL
Code Value (0008,0100) of Measurement Units Code Sequence (0040,08EA)	SH	unit	CS
Measure Units Code Sequence (0040,08EA)	Refer to note below	translation	CD
> Numeric Value Qualifier Code Sequence (0040,A301)	Refer to note below	qualifier (of translation)	CR

Details on the mapping of basic code attributes are provided in section "e. Codes" of this annex. If the Numeric Value Qualifier Code Sequence is used to convey the reason for absence of the measured value sequence item, an appropriate null flavor value shall be used to populate the physical quantity value.