PS3.17

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.

Foreword

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 [ISO/IEC Directives, Part 2].

PS3.1 should be used as the base reference for the current parts of this Standard.

1 Scope and Field of Application

This Part of the DICOM Standard contains explanatory information in the form of Normative and Informative Annexes.

2 Normative References

The following standards contain provisions which, 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.

2.1 International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC)

[ISO/IEC Directives, Part 2] ISO/IEC. 2016/05. 7.0. Rules for the structure and drafting of International Standards. http://www.iec.ch/members_experts/refdocs/iec/isoiecdir-2%7Bed7.0%7Den.pdf .

2.2 Other References

[IHE RAD TF-1] IHE International. 2020. Integrating the Healthcare Enterprise Radiology Technical Framework Volume 1 Integration Profiles. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol1.pdf .

[IHE RAD TF-2] IHE International. 2020. Integrating the Healthcare Enterprise Radiology Technical Framework Volume 2 Transactions. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf .

[RFC7233] IETF. June 2014. Hypertext Transfer Protocol (HTTP/1.1): Range Requests. http://tools.ietf.org/html/rfc7233 .

3 Definitions

For the purposes of this Standard the following definitions apply.

3.1 DICOM Introduction and Overview Definitions

This Part of the Standard makes use of the following terms defined in PS3.1:

Attribute: See Attribute in PS3.1 .
Service-Object Pair Class (SOP Class): See Service-Object Pair Class in PS3.1

3.2 DICOM Conformance

This Part of the Standard makes use of the following terms defined in PS3.2:

Standard Attribute: See Standard Attribute in PS3.2
Private Attribute: See Private Attribute in PS3.2

3.3 Information Object Definitions:

This Part of the Standard makes use of the following terms defined in PS3.3:

Attribute Tag: See Attribute Tag in PS3.3 .
Code Sequence Attribute: See Code Sequence Attribute in PS3.3 .
Information Object Definition (IOD): See Information Object Definition in PS3.3 .
Multi-frame Image: See Multi-frame Image in PS3.3 .

3.4 DICOM Service Class Specifications Definitions

This Part of the Standard makes use of the following terms defined in PS3.4:

Service-Object Pair Instance (SOP Instance): See Service-Object Pair Instance in PS3.4

3.5 DICOM Data Structures and Encoding

This Part of the Standard makes use of the following terms defined in PS3.5:

Data Set: See Data Set in PS3.5 .
Value: See Value in PS3.5 .
Value Representation (VR): See Value Representation in PS3.5 .

4 Symbols and Abbreviations

The following symbols and abbreviations are used in this Part of the Standard.

FHIR: HL7 Fast Healthcare Interoperability Resources (draft standard)

5 Conventions

Terms listed in Section 3 are capitalized throughout the document.

A Explanation of Patient Orientation (Normative)

This Annex was formerly located in Annex E “Explanation of Patient Orientation (Retired)” in PS3.3 in the 2003 and earlier revisions of the Standard.

This Annex provides an explanation of how to use the patient orientation data elements.

Figure A-1. Standard Anatomic Position Directions - Whole Body

Figure A-2. Standard Anatomic Position Directions - Hand

Figure A-3. Standard Anatomic Position Directions - Foot

As for the hand, the direction labels are based on the foot in the standard anatomic position. For the right foot, for example, RIGHT will be in the direction of the 5th toe. This assignment will remain constant through movement or positioning of the extremity. This is also true of the HEAD and FOOT directions.

Figure A-4. Views - Anterior and Lateral

Figure A-5. Planes - Whole Body - Transverse

Figure A-6. Planes - Whole Body - Sagittal

Figure A-7. Planes - Whole Body - Coronal

Figure A-8. Planes - Hand

Figure A-9. Planes - Double Obliquity

Figure A-10. Standard Anatomic Position Directions - Paired Hands

Figure A-11. Breast - MedioLateral Oblique

Figure A-12. Panoramic Zonogram Directions

B Integration of Modality Worklist and Modality Performed Procedure Step in The Original DICOM Standard (Informative)

This Annex was formerly located in Annex G “Integration of Modality Worklist and Modality Performed Procedure Step in the Original DICOM Standard (Retired)” in PS3.3 in the 2003 and earlier revisions of the Standard.

DICOM was published in 1993 and effectively addresses image communication for a number of modalities and Image Management functions for a significant part of the field of medical imaging. Since then, many additional medical imaging specialties have contributed to the extension of the DICOM Standard and developed additional Image Object Definitions. Furthermore, there have been discussions about the harmonization of the DICOM Real-World domain model with other standardization bodies. This effort has resulted in a number of extensions to the DICOM Standard. The integration of the Modality Worklist and Modality Performed Procedure Step address an important part of the domain area that was not included initially in the DICOM Standard. At the same time, the Modality Worklist and Modality Performed Procedure Step integration make steps in the direction of harmonization with other standardization bodies (CEN TC 251, HL7, etc.).

The purpose of this Annex is to show how the original DICOM Standard relates to the extension for Modality Worklist Management and Modality Performed Procedure Step. The two included figures outline the void filled by the Modality Worklist Management and Modality Performed Procedure Step specification, and the relationship between the original DICOM Data Model and the extended model.

Figure B-1. Functional View - Modality Worklist and Modality Performed Procedure Step Management in the Context of DICOM Service Classes

The management of a patient starts when the patient enters a physical facility (e.g., a hospital, a clinic, an imaging center) or even before that time. The DICOM Patient Management SOP Class provides many of the functions that are of interest to imaging departments. Figure B-1 is an example where one presumes that an order for a procedure has been issued for a patient. The order for an imaging procedure results in the creation of a Study Instance within the DICOM Study Management SOP Class. At the same time (A) the Modality Worklist Management SOP Class enables a modality operator to request the scheduling information for the ordered procedures. A worklist can be constructed based on the scheduling information. The handling of the requested imaging procedure in DICOM Study Management and in DICOM Worklist Management are closely related. The worklist also conveys patient/study demographic information that can be incorporated into the images.

Worklist Management is completed once the imaging procedure has started and the Scheduled Procedure Step has been removed from the Worklist, possibly in response to the Modality Performed Procedure Step (B). However, Study Management continues throughout all stages of the Study, including interpretation. The actual procedure performed (based on the request) and information about the images produced are conveyed by the DICOM Study Component SOP Class or the Modality Performed Procedure Step SOP Classes.

Figure B-2. Relationship of the Original Model and the Extensions for Modality Worklist and Modality Performed Procedure Step Management

Figure B-2 shows the relationship between the original DICOM Real-World model and the extensions of this Real-World model required to support the Modality Worklist and the Modality Performed Procedure Step. The new parts of the model add entities that are needed to request, schedule, and describe the performance of imaging procedures, concepts that were not supported in the original model. The entities required for representing the Worklist form a natural extension of the original DICOM Real-World model.

Common to both the original model and the extended model is the Patient entity. The Service Episode is an administrative concept that has been shown in the extended model in order to pave the way for future adaptation to a common model supported by other standardization groups including HL7, CEN TC 251 WG 3, CAP-IEC, etc. The Visit is in the original model but not shown in the extended model because it is a part of the Service Episode.

There is a 1 to 1 relationship between a Requested Procedure and the DICOM Study (A). A DICOM Study is the result of a single Requested Procedure. A Requested Procedure can result in only one Study.

A n:m relationship exists between a Scheduled Procedure Step and a Modality Performed Procedure Step (B). The concept of a Modality Performed Procedure Step is a superset of the Study Component concept contained in the original DICOM model. The Modality Performed Procedure Step SOP Classes provide a means to relate Modality Performed Procedure Steps to Scheduled Procedure Steps.

C Waveforms (Informative)

This Annex was formerly located in Annex J “Waveforms (Informative)” in PS3.3 in the 2003 and earlier revisions of the Standard.

C.1 Domain of Application

Waveform acquisition is part of both the medical imaging environment and the general clinical environment. Because of its broad use, there has been significant previous and complementary work in waveform standardization of which the following are particularly important:

ASTM E31.16 - E1467: Specification for Transferring Digital Neurophysiological Data Between Independent Computer Systems
CEN TC251 PT5-007 - prENV1064 draft: Standard Communications Protocol for Computer-Assisted Electrocardiography (SCP-ECG).
CEN TC251 PT5-021 - draft: Vital Signs Information Representation Standard (VITAL)
HL7 Automated Data SIG: HL7 Version 2.3, Chapter 7.14-20
IEEE P1073 - draft: Medical Information Bus Standard (MIB)
DICOM Section A.10 in PS3.3: Standalone Curve Information Object Definition

For DICOM, the domain of waveform standardization is waveform acquisition within the imaging context. It is specifically meant to address waveform acquisitions that will be analyzed with other data that is transferred and managed using the DICOM protocol. It allows the addition of waveform data to that context with minimal incremental cost. Further, it leverages the DICOM persistent object capability for maintaining referential relationships to other data collected in a multi-modality environment, including references necessary for multi-modality synchronization.

Waveform interchange in other clinical contexts may use different protocols more appropriate to those domains. In particular, HL7 may be used for transfer of waveform observations to general clinical information systems, and MIB may be used for real-time physiological monitoring and therapy.

The waveform information object definition in DICOM has been specifically harmonized at the semantic level with the HL7 waveform message format. The use of a common object model allows straightforward transcoding and interoperation between systems that use DICOM for waveform interchange and those that use HL7, and may be viewed as an example of common semantics implemented in the differing syntaxes of two messaging systems.

Note

HL7 allows transport of DICOM SOP Instances (information objects) encapsulated within HL7 messages. Since the DICOM and HL7 waveform semantics are harmonized, DICOM Waveform SOP Instances need not be transported as encapsulated data, as they can be transcoded to native HL7 Waveform Observation format.

C.2 Use Cases

The following are specific use case examples for waveforms in the imaging environment.

Case 1: Catheterization Laboratory - During a cardiac catheterization, several independent pieces of data acquisition equipment may be brought together for the exam. An electrocardiographic subsystem records surface ECG waveforms; an X-ray angiographic subsystem records motion images; a hemodynamic subsystem records intracardiac pressures from a sensor on the catheter. These subsystems send their acquired data by network to a repository. These data are assembled at an analytic workstation by retrieving from the repository. For a left ventriculographic procedure, the ECG is used by the physician to determine the time of maximum and minimum ventricular fill, and when coordinated with the angiographic images, an accurate estimate of the ejection fraction can be calculated. For a valvuloplasty procedure, the hemodynamic waveforms are used to calculate the pre-intervention and post-intervention pressure gradients.
Case 2: Electrophysiology Laboratory - An electrophysiological exam will capture waveforms from multiple sensors on a catheter; the placement of the catheter in the heart is captured on an angiographic image. At an analytic workstation, the exact location of the sensors can thus be aligned with a model of the heart, and the relative timing of the arrival of the electrophysiological waves at different cardiac locations can be mapped.
Case 3: Stress Exam - A stress exam may involve the acquisition of both ECG waveforms and echocardiographic ultrasound images from portable equipment at different stages of the test. The waveforms and the echocardiograms are output on an interchange disk, which is then input and read at a review station. The physician analyzes both types of data to make a diagnosis of cardiac health.

C.3 Time Synchronization Frame of Reference

Synchronization of acquisition across multiple modalities in a single study (e.g., angiography and electrocardiography) requires either a shared trigger, or a shared clock. A Synchronization Module within the Frame of Reference Information Entity specifies the synchronization mechanism. A common temporal environment used by multiple equipment is identified by a shared Synchronization Frame of Reference UID. How this UID is determined and distributed to the participating equipment is outside the scope of the Standard.

The method used for time synchronization of equipment clocks is implementation or site specific, and therefore outside the scope of this proposal. If required, standard time distribution protocols are available (e.g., NTP, IRIG, GPS).

An informative description of time distribution methods can be found at: http://web.archive.org/web/20001001065227/http://www.bancomm.com/cntpApp.htm

A second method of synchronizing acquisitions is to utilize a common reference channel (temporal fiducial), which is recorded in the data acquired from the several equipment units participating in a study, and/or that is used to trigger synchronized data acquisitions. For instance, the "X-ray on" pulse train that triggers the acquisition of frames for an X-ray angiographic SOP Instance can be recorded as a waveform channel in a simultaneously acquired hemodynamic waveform SOP Instance, and can be used to align the different object instances. Associated with this Supplement are proposed coded entry channel identifiers to specifically support this synchronization mechanism (DICOM Terminology Mapping Resource Context Group ID 3090).

C.4 Waveform Acquisition Model

Figure C.4-1 shows a canonical model of waveform data acquisition. A patient is the subject of the study. There may be several sensors placed at different locations on or in the patient, and waveforms are measurements of some physical quality (metric) by those sensors (e.g., electrical voltage, pressure, gas concentration, or sound). The sensor is typically connected to an amplifier and filter, and its output is sampled at constant time intervals and digitized. In most cases, several signal channels are acquired synchronously. The measured signal usually originates in the anatomy of the patient, but an important special case is a signal that originates in the equipment, either as a stimulus, such as a cardiac pacing signal, as a therapy, such as a radio frequency signal used for ablation, or as a synchronization signal.

Figure C.4-1. Waveform Acquisition Model

C.5 Waveform Information Model

The part of the composite information object that carries the waveform data is the Waveform Information Entity (IE). The Waveform IE includes the technical parameters of waveform acquisition and the waveform samples.

The information model, or internal organizational structure, of the Waveform IE is shown in Figure C.5-1. A waveform information object includes data from a continuous time period during which signals were acquired. The object may contain several multiplex groups, each defined by digitization with the same clock whose frequency is defined for the group. Within each multiplex group there will be one or more channels, each with a full technical definition. Finally, each channel has its set of digital waveform samples.

Figure C.5-1. DICOM Waveform Information Model

C.6 Harmonization With HL7

This Waveform IE definition is harmonized with the HL7 waveform semantic constructs, including the channel definition Attributes and the use of multiplex groups for synchronously acquired channels. The use of a common object model allows straightforward transcoding and interoperation between systems that use DICOM for waveform interchange and those that use HL7, and may be viewed as an example of common semantics implemented in the differing syntaxes of two messaging systems.

This section describes the congruence between the DICOM Waveform IE and the HL7 version 2.3 waveform message format (see HL7 version 2.3 Chapter 7, sections 7.14 - 7.20).

C.6.1 HL7 Waveform Observation

Waveforms in HL7 messages are sent in a set of OBX (Observation) Segments. Four subtypes of OBX segments are defined:

The CHN subtype defines one channel in a CD (Channel Definition) Data Type
The TIM subtype defines the start time of the waveform data in a TS (Time String) Data Type
The WAV subtype carries the waveform data in an NA (Numeric Array) or MA (Multiplexed Array) Data Type (ASCII encoded samples, character delimited)
The ANO subtype carries an annotation in a CE (Coded Entry) Data Type with a reference to a specific time within the waveform to which the annotation applies

Other segments of the HL7 message definition specify patient and study identification, whose harmonization with DICOM constructs is not defined in this Annex.

C.6.2 Channel Definition

The Waveform Module Channel Definition sequence Attribute (003A,0200) is defined in harmonization with the HL7 Channel Definition (CD) Data Type, in accordance with the following Table. Each Item in the Channel Definition sequence Attribute corresponds to an OBX Segment of subtype CHN.

Table C.6-1. Correspondence Between DICOM and HL7 Channel Definition

DICOM Attribute	DICOM Tag	HL7 CD Data Type Component
Waveform Channel Number	(003A,0202)	Channel Identifier (number&name)
Channel Label	(003A,0203)	Channel Identifier (number&name)
Channel Source Sequence	(003A,0208)	Waveform Source
Channel Source Modifier Sequence	(003A,0209)	Waveform Source
Channel Sensitivity	(003A,0210)	Channel Sensitivity and Units
Channel Sensitivity Units Sequence	(003A,0211)	Channel Sensitivity and Units
Channel Sensitivity Correction Factor	(003A,0212)	Channel Calibration Parameters (correctionfactor&baseline&timeskew)
Channel Baseline	(003A,0213)
Channel Time Skew	(003A,0214)
[Group] Sampling Frequency	(003A,001A)	Channel Sampling Frequency
Channel Minimum Value	(5400,0110)	Minimum and Maximum Data Values (minimum & maximum)
Channel Maximum Value	(5400,0112)	Minimum and Maximum Data Values (minimum & maximum)
Channel Offset	(003A,0218)	not defined in HL7
Channel Status	(003A,0205)
Filter Low Frequency	(003A,0220)
Filter High Frequency	(003A,0221)
Notch Filter Frequency	(003A,0222)
Notch Filter Bandwidth	(003A,0223)

In the DICOM information object definition, the sampling frequency is defined for the multiplex group, while in HL7 it is defined for each channel, but is required to be identical for all multiplexed channels.

Note that in the HL7 syntax, Waveform Source is a string, rather than a coded entry as used in DICOM. This should be considered in any transcoding between the two formats.

C.6.3 Timing

In HL7, the exact start time for waveform data is sent in an OBX Segment of subtype TIM. The corresponding DICOM Attributes, which must be combined to form the equivalent time string, are:

Acquisition DateTime	(0008,002A)
Multiplex Group Time Offset	(0018,1068)

C.6.4 Waveform Data

The DICOM binary encoding of data samples in the Waveform Data (5400,1010) corresponds to the ASCII representation of data samples in the HL7 OBX Segment of subtype WAV. The same channel-interleaved multiplexing used in the HL7 MA (Multiplexed Array) Data Type is used in the DICOM Waveform Data Attribute.

Because of its binary representation, DICOM uses several data elements to specify the precise encoding, as listed in the following Table. There are no corresponding HL7 data elements, since HL7 uses explicit character-delimited ASCII encoding of data samples.

Number of Waveform Channels	(003A,0005)
Number of Waveform Samples	(003A,0010)
Waveform Bits Stored	(003A,021A)
Waveform Bits Allocated	(5400,1004)
Waveform Sample Interpretation	(5400,1006)
Waveform Padding Value	(5400,100A)

C.6.5 Annotation

In HL7, Waveform Annotation is sent in an OBX Segment of subtype ANO, using the CE (Coded Entry) Data Type CE. This corresponds precisely to the DICOM Annotation using Coded Entry Sequences. However, HL7 annotation ROI is to a single point only (time reference), while DICOM allows reference to ranges of samples delimited by time or by explicit sample position.

C.7 Harmonization With SCP-ECG

The SCP-ECG standard is designed for recording routine resting electrocardiograms. Such ECGs are reviewed prior to cardiac imaging procedures, and a typical use case would be for SCP-ECG waveforms to be translated to DICOM for inclusion with the full cardiac imaging patient record.

SCP-ECG provides for either simultaneous or non-simultaneous recording of the channels, but does not provide a multiplexed data format (each channel is separately encoded). When translating to DICOM, each subset of simultaneously recorded channels may be encoded in a Waveform Sequence Item (multiplex group), and the delay to the recording of each multiplex group shall be encoded in the Multiplex Group Time Offset (0018,1068).

The electrode configuration of SCP-ECG Section 1 may be translated to the DICOM Acquisition Context (0040,0555) sequence items using TID 3401 “ECG Acquisition Context” and Context Groups 3263 and 3264.

The lead identification of SCP-ECG Section 3, a term coded as an unsigned integer, may be translated to the DICOM Waveform Channel Source (003A,0208) coded sequence using CID 3001 “ECG Lead”.

Pacemaker spike records of SCP-ECG Section 7 may be translated to items in the Waveform Annotations Sequence (0040,B020) with a code term from CID 3335 “ECG Annotation”. The annotation sequence item may record the spike amplitude in its Numeric Value and Measurement Units Attributes.

D SR Encoding Example (Informative)

This Annex was formerly located in Annex K “SR Encoding Example (Retired)” in PS3.3 in the 2003 and earlier revisions of the Standard.

The following is a simple and non-comprehensive illustration of the encoding of the Informative SR Content Tree Example in PS3.3.

SR Tree Depth	Nesting	Attribute	Tag	VR	VL (hex)	Value
		SOP Class UID	(0008,0016)	UI	001e	1.2.840.10008.5.1.4.1.1.88.33
		SOP Instance UID	(0008,0018)	UI	0012	1.2.3.4.5.6.7.300
		Study Date	(0008,0020)	DA	0008	19991029
		Content Date	(0008,0023)	DA	0008	19991029
		Study Time	(0008,0030)	TM	0006	154500
		Content Time	(0008,0033)	TM	0006	154510
		Accession Number	(0008,0050)	SH	0006	123456
		Modality	(0008,0060)	CS	0002	SR
		Manufacturer	(0008,0070)	LO	0004	WG6
		Referring Physician's Name	(0008,0090)	PN	0014	Luke^Will^^Dr.^M.D.
		Coding Scheme Identification Sequence	(0008,0110)	SQ	ffffffff
	%item
	>	Coding Scheme Designator	(0008,0102)	SH	000e	99STElsewhere
	>	Coding Scheme UID	(0008,010C)	UI	0010	1.2.3.4.6.7.8.91
	>	Responsible Organization	(0008,0116)	ST	0034	Informatics Dept St Elsewhere Hosp Boston, MA 02390
	%enditem
	%endseq
		Referenced Performed Procedure Step Sequence	(0008,1111)	SQ	ffffffff
	%endseq
		Patient's Name	(0010,0010)	PN	000e	Homer^Jane^^^
		Patient's ID	(0010,0020)	LO	0006	234567
		Patient's Birth Date	(0010,0030)	DA	0008	19991109
		Patient's Sex	(0010,0040)	CS	0002	F
		Study Instance UID	(0020,000D)	UI	0012	1.2.3.4.5.6.7.100
		Series Instance UID	(0020,000E)	UI	0012	1.2.3.4.5.6.7.200
		Study ID	(0020,0010)	SH	0006	345678
		Series Number	(0020,0011)	IS	0002	1
		Instance (formerly Image) Number	(0020,0013)	IS	0002	1
1		Value Type	(0040,a040)	CS	000a	CONTAINER
1		Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
1	%item
1	>	Code Value	(0008,0100)	SH	0006	43468-8
1	>	Coding Scheme Designator	(0008,0102)	SH	0002	LN
1	>	Code Meaning	(0008,0104)	LO	000c	X-Ray Report
1	%enditem
	%endseq
1		Continuity Of Content	(0040,a050)	CS	0008	SEPARATE
		Verifying Observer Sequence	(0040,a073)	SQ	ffffffff
	%item
	>	Verifying Organization	(0040,a027)	LO	0004	WG6
	>	Verification DateTime	(0040,a030)	DT	000e	19991029154510
	>	Verifying Observer Name	(0040,a075)	PN	000e	Jones^Joe^^Dr^
	>	Verifying Observer Identification Code Sequence	(0040,a088)	SQ	ffffffff
	%item
	>>	Code Value	(0008,0100)	SH	0006	369842
	>>	Coding Scheme Designator	(0008,0102)	SH	000e	99STElsewhere
	>>	Code Meaning	(0008,0104)	LO	0006	369842
	%enditem
	%endseq
	%enditem
	%endseq
		Referenced Request Sequence	(0040,a370)	SQ	ffffffff
	%item
	>	Accession Number	(0008,0050)	SH	0006	123456
	>	Referenced Study Sequence	(0008,1110)	SQ	ffffffff
	%endseq
	>	Study Instance UID	(0020,000D)	UI	0012	1.2.3.4.5.6.7.100
	>	Requested Procedure Description	(0032,1060)	LO	000a	Chest Xray
	>	Requested Procedure Code Sequence	(0032,1064)	SQ	ffffffff
	%item
	>>	Code Value	(0008,0100)	SH	0006	42272-5
	>>	Coding Scheme Designator	(0008,0102)	SH	0002	LN
	>>	Code Meaning	(0008,0104)	LO	001a	Chest X-Ray PA and lateral
	%enditem
	%endseq
	>	Requested Procedure ID	(0040,1001)	SH	0006	012340
	>	Placer Order Number/Imaging Service Request	(0040,2016)	LO	0
	>	Filler Order Number/Imaging Service Request	(0040,2017)	LO	0
	%enditem
	%endseq
		Performed Procedure Code Sequence	(0040,a372)	SQ	ffffffff
	%item
	>	Code Value	(0008,0100)	SH	0006	42272-5
	>	Coding Scheme Designator	(0008,0102)	SH	0002	LN
	>	Code Meaning	(0008,0104)	LO	001a	Chest X-Ray PA and lateral
	%enditem
	%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	0008	1.2.3.4
	>>>	Referenced SOP Instance UID	(0008,1155)	UI	000a	1.2.3.4.5
	%enditem
	%endseq
	>>	Series Instance UID	(0020,000E)	UI	0012	1.2.3.4.5.6.7.200
	%enditem
	%endseq
	>	Study Instance UID	(0020,000D)	UI	0012	1.2.3.4.5.6.7.100
	%enditem
	%endseq
		Completion Flag	(0040,a491)	CS	0008	COMPLETE
		Verification Flag	(0040,a493)	CS	0008	VERIFIED
1		Content Sequence	(0040,a730)	SQ	ffffffff
1.1	%item
1.1	>	Relationship Type	(0040,a010)	CS	0010	HAS OBS CONTEXT
1.1	>	Value Type	(0040,a040)	CS	0006	PNAME
1.1	>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
1.1	%item
1.1	>>	Code Value	(0008,0100)	SH	0006	121008
1.1	>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.1	>>	Code Meaning	(0008,0104)	LO	0014	Person Observer Name
1.1	%enditem
1.1	%endseq
1.1	>	Person Name	(0040,a123)	PN	0010	Smith^John^^Dr^
1.1	%enditem
1.2	%item
1.2	>	Relationship Type	(0040,a010)	CS	0010	HAS OBS CONTEXT
1.2	>	Value Type	(0040,a040)	CS	0006	UIDREF
1.2	>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
1.2	%item
1.2	>>	Code Value	(0008,0100)	SH	0006	121018
1.2	>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.2	>>	Code Meaning	(0008,0104)	LO	001c	Procedure Study Instance UID
1.2	%enditem
1.2	%endseq
1.2	>	UID	(0040,a124)	UI	0012	1.2.3.4.5.6.7.100
1.2	%enditem
1.3	%item
1.3	>	Relationship Type	(0040,a010)	CS	0010	HAS OBS CONTEXT
1.3	>	Value Type	(0040,a040)	CS	0006	PNAME
1.3	>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
1.3	%item
1.3	>>	Code Value	(0008,0100)	SH	0006	121029
1.3	>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.3	>>	Code Meaning	(0008,0104)	LO	000c	Subject Name
1.3	%enditem
1.3	%endseq
1.3	>	Person Name	(0040,a123)	PN	000e	Homer^Jane^^^
1.3	%enditem
1.4	%item
1.4	>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.4	>	Value Type	(0040,a040)	CS	0004	CODE
1.4	>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
1.4	%item
1.4	>>	Code Value	(0008,0100)	SH	0006	121071
1.4	>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.4	>>	Code Meaning	(0008,0104)	LO	0008	Finding
1.4	%enditem
1.4	%endseq
1.4	>	Concept Code Sequence	(0040,a168)	SQ	ffffffff
1.4	%item
1.4	>>	Code Value	(0008,0100)	SH	000A	118538004
1.4	>>	Coding Scheme Designator	(0008,0102)	SH	0004	SCT
1.4	>>	Code Meaning	(0008,0104)	LO	0004	Mass
1.4	%enditem
1.4	%endseq
1.4	>	Content Sequence	(0040,a730)	SQ	ffffffff
1.4.1	%item
1.4.1	>>	Relationship Type	(0040,a010)	CS	000e	HAS PROPERTIES
1.4.1	>>	Value Type	(0040,a040)	CS	0004	NUM
1.4.1	>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
1.4.1	%item
1.4.1	>>>	Code Value	(0008,0100)	SH	0008	81827009
1.4.1	>>>	Coding Scheme Designator	(0008,0102)	SH	0004	SCT
1.4.1	>>>	Code Meaning	(0008,0104)	LO	0008	Diameter
1.4.1	%enditem
1.4.1	%endseq
1.4.1	>>	Measured Value Sequence	(0040,a300)	SQ	ffffffff
1.4.1	%item
1.4.1	>>>	Measurement Units Code Sequence	(0040,08ea)	SQ	ffffffff
1.4.1	%item
1.4.1	>>>>	Code Value	(0008,0100)	SH	0002	cm
1.4.1	>>>>	Coding Scheme Designator	(0008,0102)	SH	0004	UCUM
1.4.1	>>>>	Code Meaning	(0008,0104)	LO	0002	cm
1.4.1	%enditem
1.4.1	%endseq
1.4.1	>>>	Numeric Value	(0040,a30a)	DS	0004	1.3
1.4.1	%enditem
1.4.1	%endseq
1.4.1	%enditem
1.4.2	%item
1.4.2	>>	Relationship Type	(0040,a010)	CS	000e	HAS PROPERTIES
1.4.2	>>	Value Type	(0040,a040)	CS	0004	CODE
1.4.2	>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
1.4.2	%item
1.4.2	>>>	Code Value	(0008,0100)	SH	000A	112233002
1.4.2	>>>	Coding Scheme Designator	(0008,0102)	SH	0004	SCT
1.4.2	>>>	Code Meaning	(0008,0104)	LO	0006	Margin
1.4.2	%enditem
1.4.2	%endseq
1.4.2	>>	Concept Code Sequence	(0040,a168)	SQ	ffffffff
1.4.2	%item
1.4.2	>>>	Code Value	(0008,0100)	SH	0006	112136
1.4.2	>>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.4.2	>>>	Code Meaning	(0008,0104)	LO	000a	Spiculated
1.4.2	%enditem
1.4.2	%endseq
1.4.2	%enditem
1.4	%endseq
1.4	%enditem
1.5	%item
1.5	>	Referenced SOP Sequence	(0008,1199)	SQ	ffffffff
1.5	%item
1.5	>>	Referenced SOP Class UID	(0008,1150)	UI	0008	1.2.3.4
1.5	>>	Referenced SOP Instance UID	(0008,1155)	UI	000a	1.2.3.4.5
1.5	%enditem
1.5	%endseq
1.5	>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.5	>	Value Type	(0040,a040)	CS	0006	IMAGE
1.5	>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
1.5	%item
1.5	>>	Code Value	(0008,0100)	SH	0006	121079
1.5	>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.5	>>	Code Meaning	(0008,0104)	LO	0008	Baseline
1.5	%enditem
1.5	%endseq
1.5	%enditem
1.6	%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
1.6	%item
1.6	>>	Code Value	(0008,0100)	SH	0006	55110-1
1.6	>>	Coding Scheme Designator	(0008,0102)	SH	0002	LN
1.6	>>	Code Meaning	(0008,0104)	LO	000c	Conclusions
1.6	%enditem
1.6	%endseq
1.6		Continuity Of Content	(0040,a050)	CS	0008	SEPARATE
1.6	>	Content Sequence	(0040,a730)	SQ	ffffffff
1.6.1	%item
1.6.1	>>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.6.1	>>	Value Type	(0040,a040)	CS	0004	CODE
1.6.1	>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
1.6.1	%item
1.6.1	>>>	Code Value	(0008,0100)	SH	0006	121077
1.6.1	>>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.6.1	>>>	Code Meaning	(0008,0104)	LO	000a	Conclusion
1.6.1	%enditem
1.6.1	%endseq
1.6.1	>>	Concept Code Sequence	(0040,a168)	SQ	ffffffff
1.6.1	%item
1.6.1	>>>	Code Value	(0008,0100)	SH	0006	888000
1.6.1	>>>	Coding Scheme Designator	(0008,0102)	SH	000e	99STElsewhere
1.6.1	>>>	Code Meaning	(0008,0104)	LO	0014	Probable malignancy
1.6.1	%enditem
1.6.1	%endseq
1.6.1	>>	Content Sequence	(0040,a730)	SQ	ffffffff
1.6.1.1	%item
1.6.1.1	>>>	Relationship Type	(0040,a010)	CS	000e	INFERRED FROM
1.6.1.1	>>>	Referenced Content Item Identifier	(0040,db73)	UL	000c	0001,0004,0002
1.6.1.1	%enditem
1.6.1.2	%item
1.6.1.2	>>>	Relationship Type	(0040,a010)	CS	000e	INFERRED FROM
1.6.1.2	>>>	Referenced Content Item Identifier	(0040,db73)	UL	000c	0001,0007,0001
1.6.1.2	%enditem
1.6.1	%endseq
1.6.1	%enditem
1.6	%endseq
1.6	%enditem
1.7	%item
1.7	>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.7	>	Value Type	(0040,a040)	CS	000a	CONTAINER
1.7	>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
1.7	%item
1.7	>>	Code Value	(0008,0100)	SH	0006	59776-5
1.7	>>	Coding Scheme Designator	(0008,0102)	SH	0006	LN
1.7	>>	Code Meaning	(0008,0104)	LO	0008	Findings
1.7	%enditem
1.7	%endseq
1.7		Continuity Of Content	(0040,a050)	CS	0008	SEPARATE
1.7	>	Content Sequence	(0040,a730)	SQ	ffffffff
1.7.1	%item
1.7.1	>>	Relationship Type	(0040,a010)	CS	0008	CONTAINS
1.7.1	>>	Value Type	(0040,a040)	CS	0006	SCOORD
1.7.1	>>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
1.7.1	%item
1.7.1	>>>	Code Value	(0008,0100)	SH	0006	121080
1.7.1	>>>	Coding Scheme Designator	(0008,0102)	SH	0004	DCM
1.7.1	>>>	Code Meaning	(0008,0104)	LO	001c	Best illustration of finding
1.7.1	%enditem
1.7.1	%endseq
1.7.1	>>	Content Sequence	(0040,a730)	SQ	ffffffff
1.7.1.1	%item
1.7.1.1	>>>	Referenced SOP Sequence	(0008,1199)	SQ	ffffffff
1.7.1.1	%item
1.7.1.1	>>>>	Referenced SOP Class UID	(0008,1150)	UI	0008	1.2.3.4
1.7.1.1	>>>>	Referenced SOP Instance UID	(0008,1155)	UI	000a	1.2.3.4.6
1.7.1.1	%enditem
1.7.1.1	%endseq
1.7.1.1	>>>	Relationship Type	(0040,a010)	CS	000e	SELECTED FROM
1.7.1.1	>>>	Value Type	(0040,a040)	CS	0006	IMAGE
1.7.1.1	%enditem
1.7.1	%endseq
1.7.1	>>	Graphic Data	(0070,0022)	FL	0020	0,0,0,0,0,0,0,0
1.7.1	>>	Graphic Type	(0070,0023)	CS	0008	POLYLINE
1.7.1	%enditem
1.7	%endseq
1.7	%enditem
1.8	%item
1.8	>	Relationship Type	(0040,a010)	CS	0010	HAS CONCEPT MOD
1.8	>	Value Type	(0040,a040)	CS	0004	CODE
1.8	>	Concept Name Code Sequence	(0040,a043)	SQ	ffffffff
1.8	%item
1.8	>>	Code Value	(0008,0100)	SH	000a	LP28726-5
1.8	>>	Coding Scheme Designator	(0008,0102)	SH	0002	LN
1.8	>>	Code Meaning	(0008,0104)	LO	0006	Views
1.8	%enditem
1.8	%endseq
1.8	>	Concept Code Sequence	(0040,a168)	SQ	ffffffff
1.8	%item
1.8	>>	Code Value	(0008,0100)	SH	000a	LP33431-5
1.8	>>	Coding Scheme Designator	(0008,0102)	SH	0002	LN
1.8	>>	Code Meaning	(0008,0104)	LO	000e	PA and Lateral
1.8	%enditem
1.8	%endseq
1.8	%enditem
1	%endseq

E Mammography CAD (Informative)

This Annex was formerly located in Annex L “Mammography CAD (Retired)” in PS3.3 in the 2003 and earlier revisions of the Standard.

E.1 Mammography CAD SR Content Tree Structure

The templates for the Mammography CAD SR IOD are defined in Mammography CAD SR IOD Templates in PS3.16 . Relationships defined in the Mammography CAD SR IOD templates are by-value, unless otherwise stated. Content items referenced from another SR object instance, such as a prior Mammography CAD SR, are inserted by-value in the new SR object instance, with appropriate original source observation context. It is necessary to update Rendering Intent, and referenced content item identifiers for by-reference relationships, within content items paraphrased from another source.

Figure E.1-1. Top Levels of Mammography CAD SR Content Tree

The Document Root, Image Library, Summaries of Detections and Analyses, and CAD Processing and Findings Summary sub-trees together form the content tree of the Mammography CAD SR IOD. There are no constraints regarding the 1-n multiplicity of the Individual Impression/Recommendation or its underlying structure, other than the TID 4001 “Mammography CAD Overall Impression/Recommendation” and TID 4003 “Mammography CAD Individual Impression/Recommendation” requirements in PS3.16. Individual Impression/Recommendation containers may be organized, for example per image, per finding or composite feature, or some combination thereof.

Figure E.1-2. Summary of Detections and Analyses Levels of Mammography CAD SR Content Tree

The Summary of Detections and Summary of Analyses sub-trees identify the algorithms used and the work done by the CAD device, and whether or not each process was performed on one or more entire images or selected regions of images. The findings of the detections and analyses are not encoded in the summary sub-trees, but rather in the CAD Processing and Findings Summary sub-tree. CAD processing may produce no findings, in which case the sub-trees of the CAD Processing and Findings Summary sub-tree are incompletely populated. This occurs in the following situations:

All algorithms succeeded, but no findings resulted
Some algorithms succeeded, some failed, but no findings resulted
All algorithms failed

Note

If the tree contains no Individual Impression/Recommendation nodes and all attempted detections and analyses succeeded then the mammography CAD device made no findings.
Detections and Analyses that are not attempted are not listed in the Summary of Detections and Summary of Analyses trees.
If the code value of the Summary of Detections or Summary of Analyses codes in TID 4000 “Mammography CAD Document Root” is "Not Attempted" then no detail is provided as to which algorithms were not attempted.

Figure E.1-3. Example of Individual Impression/Recommendation Levels of Mammography CAD SR Content Tree

The shaded area in Figure E.1-3 demarcates information resulting from Detection, whereas the unshaded area is information resulting from Analysis. This distinction is used in determining whether to place algorithm identification information in the Summary of Detections or Summary of Analyses sub-trees.

The clustering of calcifications within a single image is considered to be a Detection process that results in a Single Image Finding. The spatial correlation of a calcification cluster in two views, resulting in a Composite Feature, is considered Analysis. The clustering of calcifications in a single image is the only circumstance in which a Single Image Finding can result from the combination of other Single Image Findings, which must be Individual Calcifications.

Once a Single Image Finding or Composite Feature has been instantiated, it may be referenced by any number of Composite Features higher in the tree.

E.2 Mammography CAD SR Observation Context Encoding

Any content item in the Content tree that has been inserted (i.e., duplicated) from another SR object instance has a HAS OBS CONTEXT relationship to one or more content items that describe the context of the SR object instance from which it originated. This mechanism may be used to combine reports (e.g., Mammography CAD 1, Mammography CAD 2, Human).
By-reference relationships within Single Image Findings and Composite Features paraphrased from prior Mammography CAD SR objects need to be updated to properly reference Image Library Entries carried from the prior object to their new positions in the present object.

The Impression/Recommendation section of the SR Document Content tree of a Mammography CAD SR IOD may contain a mixture of current and prior single image findings and composite features. The content items from current and prior contexts are target content items that have a by-value INFERRED FROM relationship to a Composite Feature content item. Content items that come from a context other than the Initial Observation Context have a HAS OBS CONTEXT relationship to target content items that describe the context of the source document.

In Figure E.2-1, Composite Feature and Single Image Finding are current, and Single Image Finding (from Prior) is duplicated from a prior document.

Figure E.2-1. Example of Use of Observation Context

E.3 Mammography CAD SR Examples

The following is a simple and non-comprehensive illustration of an encoding of the Mammography CAD SR IOD for Mammography computer aided detection results. For brevity, some Mandatory content items are not included, such as several acquisition context content items for the images in the Image Library.

E.3.1 Example 1: Calcification and Mass Detection With No Findings

A mammography CAD device processes a typical screening mammography case, i.e., there are four films and no cancer. Mammography CAD runs both density and calcification detection successfully and finds nothing. The mammograms resemble:

Figure E.3-1. Mammograms as Described in Example 1

The content tree structure would resemble:

Node	Code Meaning of Concept Name	Code Meaning or Example Value	TID
1	Mammography CAD Report		TID 4000
1.1	Image Library		TID 4000
1.1.1		IMAGE 1	TID 4020
1.1.1.1	Image Laterality	Right	TID 4020
1.1.1.2	Image View	Cranio-caudal	TID 4020
1.1.1.3	Study Date	19980101	TID 4020
1.1.2		IMAGE 2	TID 4020
1.1.2.1	Image Laterality	Left	TID 4020
1.1.2.2	Image View	Cranio-caudal	TID 4020
1.1.2.3	Study Date	19980101	TID 4020
1.1.3		IMAGE 3	TID 4020
1.1.3.1	Image Laterality	Right	TID 4020
1.1.3.2	Image View	Medio-lateral oblique	TID 4020
1.1.3.3	Study Date	19980101	TID 4020
1.1.4		IMAGE 4	TID 4020
1.1.4.1	Image Laterality	Left	TID 4020
1.1.4.2	Image View	Medio-lateral oblique	TID 4020
1.1.4.3	Study Date	19980101	TID 4020
1.2	CAD Processing and Findings Summary	All algorithms succeeded; without findings	TID 4001
1.3	Summary of Detections	Succeeded	TID 4000
1.3.1	Successful Detections		TID 4015
1.3.1.1	Detection Performed	Mammography breast density	TID 4017
1.3.1.1.1	Algorithm Name	"Density Detector"	TID 4019
1.3.1.1.2	Algorithm Version	"V3.7"	TID 4019
1.3.1.1.3		Reference to node 1.1.1	TID 4017
1.3.1.1.4		Reference to node 1.1.2	TID 4017
1.3.1.1.5		Reference to node 1.1.3	TID 4017
1.3.1.1.6		Reference to node 1.1.4	TID 4017
1.3.1.2	Detection Performed	Individual Calcification	TID 4017
1.3.1.2.1	Algorithm Name	"Calc Detector"	TID 4019