Table of Contents
List of Figures
List of Tables
List of Examples
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 [ISO/IEC Directives, Part 2].
PS3.1 should be used as the base reference for the current parts of this Standard.
DICOM® is the registered trademark of the National Electrical Manufacturers Association for its standards publications relating to digital communications of medical information, all rights reserved.
HL7® and CDA® are the registered trademarks of Health Level Seven International, all rights reserved.
SNOMED®, SNOMED Clinical Terms®, SNOMED CT® are the registered trademarks of the International Health Terminology Standards Development Organisation (IHTSDO), all rights reserved.
LOINC® is the registered trademark of Regenstrief Institute, Inc, all rights reserved.
This Part of the DICOM Standard contains explanatory information in the form of Normative and Informative Annexes.
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.
[ISO/IEC Directives, Part 2] 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 .
[IHE RAD TF-1] 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] 2020. Integrating the Healthcare Enterprise Radiology Technical Framework Volume 2 Transactions. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf .
[RFC7233] June 2014. Hypertext Transfer Protocol (HTTP/1.1): Range Requests. http://tools.ietf.org/html/rfc7233 .
For the purposes of this Standard the following definitions apply.
This Part of the Standard makes use of the following terms defined in PS3.1:
This Part of the Standard makes use of the following terms defined in PS3.2:
This Part of the Standard makes use of the following terms defined in PS3.3:
This Part of the Standard makes use of the following terms defined in PS3.4:
This Part of the Standard makes use of the following terms defined in PS3.5:
Terms listed in Section 3 are capitalized throughout the document.
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.
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.
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.
This Annex was formerly located in Annex J “Waveforms (Informative)” in PS3.3 in the 2003 and earlier revisions of the Standard.
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:
Specification for Transferring Digital Neurophysiological Data Between Independent Computer Systems
Standard Communications Protocol for Computer-Assisted Electrocardiography (SCP-ECG).
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.
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.
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.
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).
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.
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.
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).
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.
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
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.
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:
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.
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.
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.
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.
This Annex was formerly located in Annex L “Mammography CAD (Retired)” in PS3.3 in the 2003 and earlier revisions of the Standard.
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.
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.
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:
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.
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.
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.