Table of Contents
List of Figures
List of Tables
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 specifies the set of Information Object Definitions (IODs) that provide an abstract definition of real-world objects applicable to communication of digital medical information. For each IOD, this Part specifies:
For each IOD, this Part does not specify:
This Part is related to other parts of the DICOM Standard in that:
PS3.4 Service Class Specifications, specifies application level services by grouping DIMSE services with IODs as defined in this Part;
PS3.5 Data Structure and Semantics, defines the data encoding used in the DIMSE Protocol when applied to IODs defined in this Part;
PS3.6 Data Dictionary, contains an index by Tag of all IOD Attributes defined in this Part. This index includes the Value Representation and Value Multiplicity for each Attribute;
PS3.7 Message Exchange Protocol, defines the DIMSE Services and Protocol that may be applied to IODs defined in this Part.
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 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 .
[ISO 7498-1] 1994. Information Processing Systems - Open Systems Interconnection - Basic Reference Model.
[ISO 7498-2] 1989. Information processing systems - Open Systems Interconnection - Basic reference Model - Part 2: Security Architecture.
[ISO/TR 8509] Information Processing Systems - Open Systems Interconnection - Service Conventions. ISO/TR 8509 has been withdrawn. See ISO/IEC 2382-26:1993 Information technology - Vocabulary - Part 26: Open systems interconnection .
[ISO 8825-1] 2002. Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[ISO/IEC 8859-1] 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 1: Latin alphabet No. 1.
[ISO/IEC 8859-2] 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 2: Latin alphabet No. 2.
[ISO/IEC 8859-3] 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 3: Latin alphabet No. 3.
[ISO/IEC 8859-4] 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 4: Latin alphabet No. 4.
[ISO/IEC 8859-5] 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 5: Latin/Cyrillic alphabet.
[ISO/IEC 8859-6] 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 6: Latin/Arabic alphabet.
[ISO/IEC 8859-7] 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 7: Latin/Greek alphabet.
[ISO/IEC 8859-8] 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 8: Latin/Hebrew alphabet.
[ISO/IEC 8859-9] 1989. Information processing - 8-bit single-byte coded graphic character sets - Part 9: Latin alphabet No. 5.
[ISO/IEC 8859-15] 1999. Information technology — 8-bit single-byte coded graphic character sets — Part 15: Latin alphabet No. 9.
[ISO/IEC 10118-3] 1998. Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions (RIPEMD-160 reference). The draft RIPEMD-160 specification and sample code are also available at http://homes.esat.kuleuven.be/~bosselae/ripemd160.html .
[ISO/IEC 10646] 2020. Information Technology - Universal Coded Character Set (UCS). ISO/IEC 10646-2020 is the same as Unicode Version 13.0, available at http://unicode.org .
[ISO/IEC 10918-1] 1994. JPEG Standard for digital compression and encoding of continuous-tone still images. Part 1 - Requirements and implementation guidelines.
[ISO/IEC 10918-5] 2013. JPEG Standard for digital compression and encoding of continuous-tone still images. Part 5 - JPEG File Interchange Format (JFIF).
[ISO 11664-4] 2008. Colorimetry - Part 4: CIE 1976 L*a*b* Colour space. ISO 11664-4 2008 is the same as CIE S 014-4/E:2007 .
[ISO 12232] 2006. Photography - Digital still cameras - Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index. http://www.iso.org/standard/37777.html .
[ISO 12233] 2018. Photography - Electronic still picture imaging - Resolution and spatial frequency responses. http://www.iso.org/standard/71696.html .
[ISO 12234-2] 2001. Electronic still-picture imaging - Removable memory - Part 2: TIFF/EP image data formats. http://www.iso.org/standard/29377.html .
[ISO/IEC 13818-1] 2000. Information technology - Generic coding of moving pictures and associated audio information: Systems.
[ISO/IEC 13818-2] 2000. Information technology - Generic coding of moving pictures and associated audio information: Video.
[ISO/IEC 13818-3] 1998. Information technology - Generic coding of moving pictures and associated audio information - Part 3: Audio.
[ISO/IEC 13818-4] 2004. Information technology - Generic coding of moving pictures and associated audio information - Part 4: Conformance testing.
[ISO/IEC 14495-1] 1997. Lossless and near-lossless coding of continuous tone still images (JPEG-LS).
[ISO/IEC 14496-10] 2009. Information technology - Coding of audio-visual objects - Part 210: Advanced Video Coding. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52974 .
[ISO/IEC 14496-22] Information technology - Coding of audio-visual objects - Part 22: Open Font Format. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52136 .
[ISO 14524] 2009. Photography - Electronic still-picture cameras - Methods for measuring opto-electronic conversion functions (OECFs). http://www.iso.org/standard/43527.html .
[ISO 15076-1] 2005. Image technology colour management - Architecture, profile format, and data structure. Also available as ICC.1:2004-10 (Profile version 4.2.0.0), International Color Consortium, available at http://www.color.org/v4spec.xalter .
[ISO/IEC 18181-1] 2022. Information technology - JPEG XL Image Coding System - Part 1 Core Coding System.
[ISO 21320-1] 2015. Information technology – Document Container File – Part 1: Core. http://standards.iso.org/ittf/PubliclyAvailableStandards/c060101_ISO_IEC_21320-1_2015.zip .
[ISO 22028-2] 2013. Photography and graphic technology - Extended colour encodings for digital image storage, manipulation and interchange - Part 2: Reference output medium metric RGB colour image encoding (ROMM RGB). http://www.iso.org/iso/catalogue_detail.htm?csnumber=56591 .
[ISO/IEC 23008-2] Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 2: High efficiency video coding. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=67660 .
[ISO 32000-1] Document management - Portable document format - Part 1. http://www.iso.org/iso/catalogue_detail.htm?csnumber=51502 .
[IEC 60601-2-1] 2020. Ed.4. Medical Electrical Equipment - Part 2-1: Particular requirements for the basic safety and essential performance of electron accelerators in the range 1 MeV to 50 MeV.
[IEC 60601-2-33] 2010. Ed.3.1. Medical Electrical Equipment - Part 2-33: Particular requirements for the basic safety and essential performance of magnetic resonance equipment for medical diagnosis.
[IEC 60601-2-44] 2016. Ed.3.2. Medical Electrical Equipment - Part 2-44: Particular Requirements for the Safety of X-Ray Equipment for Computed Tomography.
[IEC 60601-2-63] 2012. Medical Electrical Equipment - Part 2-63: Particular requirements for the basic safety and essential performance of dental extra-oral X-Ray equipment.
[IEC 60601-2-64] 2014. Medical Electrical Equipment - Part 2-64: Particular requirements for the basic safety and essential performance of light ion beam medical electrical equipment.
[IEC 61966-2.1] 1999. Ed 1.0. Multimedia systems and equipment - colour measurement and management - Part 2.1: colour management - Default RGB colour space - sRGB.
[IEC 62494-1] 2008. Medical electrical equipment - Exposure index of digital X-Ray imaging systems - Part 1: Definitions and requirements for general radiography.
[IEC 62563-1] 2009. Ed 1.0. Medical Electrical Equipment - Medical image display systems - Part 1: Evaluation methods.
[ISO IR 13] 1975. Registration - The Japanese KATAKANA graphic set of characters. http://www.itscj.ipsj.or.jp/iso-ir/013.pdf .
[ISO IR 14] 1975. Registration - The Japanese Roman graphic set of characters. http://www.itscj.ipsj.or.jp/iso-ir/014.pdf .
[ISO IR 100] 1986. Registration - Right-hand Part of the Latin Alphabet Nr. 1. http://www.itscj.ipsj.or.jp/iso-ir/100.pdf .
[ISO IR 101] 1986. Registration - Right-hand Part of the Latin Alphabet Nr. 2. http://www.itscj.ipsj.or.jp/iso-ir/101.pdf .
[ISO IR 109] 1986. Registration - Right-hand Part of the Latin Alphabet Nr. 3. http://www.itscj.ipsj.or.jp/iso-ir/109.pdf .
[ISO IR 110] 1986. Registration - Right-hand Part of the Latin Alphabet Nr. 4. http://www.itscj.ipsj.or.jp/iso-ir/110.pdf .
[ISO IR 126] 1986. Registration - Right-hand Part of the Latin/Greek alphabet. http://www.itscj.ipsj.or.jp/iso-ir/126.pdf .
[ISO IR 127] 1986. Registration - Right-hand Part of Latin/Arabic alphabet. http://www.itscj.ipsj.or.jp/iso-ir/127.pdf .
[ISO IR 138] 1987. Registration - Latin/Hebrew alphabet. http://www.itscj.ipsj.or.jp/iso-ir/138.pdf .
[ISO IR 144] 1988. Registration - Cyrillic Part of the Latin/Cyrillic Alphabet. http://www.itscj.ipsj.or.jp/iso-ir/144.pdf .
[ISO IR 148] 1988. Registration - Right-hand Part of Latin alphabet No. 5. http://www.itscj.ipsj.or.jp/iso-ir/148.pdf .
[ISO IR 166] 1992. Registration - Thai Character Set. http://www.itscj.ipsj.or.jp/iso-ir/166.pdf .
[ISO IR 192] 1996. Registration - UCS Transformation Format (UTF-8), implementation level 3, without standard return. http://www.itscj.ipsj.or.jp/iso-ir/192.pdf .
[ISO IR 203] 1998. Registration - European supplementary Latin set ("Latin 9"). http://www.itscj.ipsj.or.jp/iso-ir/203.pdf .
[ITU-T X.509] 2000. Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks. ITU-T Recommendation X.509 is similar to ISO/IEC 9594-8 1990. However, the ITU-T recommendation is the more familiar form, and was revised in 1993 and 2000, with two sets of corrections in 2001. ITU-T was formerly known as CCITT. .
[RFC1321] The MD5 Message-Digest Algorithm. http://tools.ietf.org/html/rfc1321 .
[RFC1951] DEFLATE Compressed Data Format Specification Version 1.3. http://tools.ietf.org/html/rfc1952 .
[RFC1952] GZIP file format specification version 4.3. http://tools.ietf.org/html/rfc1952 .
[RFC2046] November 1996. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. http://tools.ietf.org/html/rfc2046 .
[RFC2437] October 1998. PKCS #1 RSA Cryptography Specifications Version 2.0. http://tools.ietf.org/html/rfc2437 . The RSA Encryption Standard is also defined in informative Annex A of ISO/IEC 9796, and in Normative Annex A of the CEN/TC251 European Prestandard prENV 12388:1996. .
[RFC3161] Internet X.509 Public Key Infrastructure; Time Stamp Protocols. http://tools.ietf.org/html/rfc3161 .
[RFC3986] Uniform Resource Identifiers (URI): Generic Syntax. http://tools.ietf.org/html/rfc3986 .
[RFC5652] September 2009. Cryptographic Message Syntax. http://tools.ietf.org/html/rfc5652 .
[RFC6151] March 2011. Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms. http://tools.ietf.org/html/rfc6151 .
[RFC7230] Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. http://tools.ietf.org/html/rfc7230 .
[RFC7231] Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. http://tools.ietf.org/html/rfc7231 .
[RFC7530] Network File System (NFS) Version 4 Protocol. http://tools.ietf.org/html/rfc7530 .
[HL7 V2.5] 2003. HL7 Standard Version 2.5 - An Application Protocol for Electronic Data Exchange in Healthcare Environments. http://www.hl7.org/documentcenter/private/standards/V25/HL7_Messaging_v25_PDF.zip .
[HL7 V2.9.1] 2024. HL7 Version 2.9.1 Messaging Standard - An Application Protocol for Electronic Data Exchange in Healthcare Environments. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=649 .
[HL7 CDA R1] 2000. HL7 Version 3 Standard: Clinical Document Architecture Framework, Release 1. http://www.hl7.org/documentcenter/private/standards/cda/r1/HL7_CDA_R1_FINAL.zip .
[HL7 CDA R2] 2005. HL7 Version 3 Standard: Clinical Document Architecture Framework, Release 2. http://www.hl7.org/documentcenter/private/standards/cda/r2/cda_r2_normativewebedition2010.zip .
[HL7 SPL R1.0] 2024. HL7 Structured Product Labeling Standard, Release 1.0. http://www.hl7.org/documentcenter/private/standards/SPL/SPL_Specification_ANSI_R1.0-2004.zip .
[HL7 Gender Harmony Model] 2021. The HL7 Informative Document: Gender Harmony - Modeling Sex and Gender Representation, Release 1. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=564 .
[HL7 Gender Harmony IG] . HL7 Cross Paradigm Implementation Guide: Gender Harmony - Sex and Gender Representation, Edition 1. http://hl7.org/xprod/ig/uv/gender-harmony/ .
[HL7 CDA R2.0 Gender Harmony IG] . HL7 CDA® R2 Implementation Guide: Gender Harmony - Sex and Gender Representation, Edition 1. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=633 .
[HL7 FHIR 5 Patient Gender] HL7 FHIR Release 5 - Patient Gender and Sex. http://hl7.org/fhir/R5/patient.html#gender .
[FIPS PUB 46] . Data Encryption Standard (DES). Withdrawn . http://csrc.nist.gov/publications/fips/archive/fips46-3/fips46-3.pdf .
[FIPS PUB 180-4] August 2015. Secure Hash Standard (SHS). http://doi.org/10.6028/NIST.FIPS.180-4 .
[FIPS PUB 202] August 2015. SHA-3 Standard. http://doi.org/10.6028/NIST.FIPS.202 .
[ACR-NEMA 300-1985] 1985. Digital Imaging and Communications. http://dicom.nema.org/medical/dicom/1985/ACR-NEMA_300-1985.pdf .
[ACR-NEMA 300-1988] 1988. Digital Imaging and Communications. http://dicom.nema.org/medical/dicom/1988/ACR-NEMA_300-1988.pdf .
[Adobe RGB] 1998. 2005-05. Adobe RGB (1998) Color Image Encoding. http://www.adobe.com/digitalimag/pdfs/AdobeRGB1998.pdf .
[Anderson 1986] Medical Physics. 1986. 6. 898-903. “A "natural" volume-dose histogram for brachytherapy”. doi:10.1118/1.595815
[ANSI X9.52] 1998. Triple Data Encryption Algorithm Modes of Operation, Accredited Standards Committee (ASC) X9, Financial Services.
[APEX] August 4, 2007. APEX — The Additive System of Photographic Exposure. http://dougkerr.net/Pumpkin/articles/APEX.pdf .
[BI-RADS®] 1998. 3.0. Breast Imaging Reporting and Data System Atlas. http://www.acr.org/Quality-Safety/Resources/BIRADS .
[ECMA 235] 1996. The ECMA GSS-API Mechanism. http://www.ecma-international.org/publications/standards/Ecma-235.htm .
[EXIF 2.31] July 2016. 2.31. Exchangeable Image File Format for Digital Still Cameras - CIPA DC-008, JEITA CP-3451C Translation. http://cipa.jp/std/documents/e/DC-008-Translation-2016-E.pdf .
[FDA UDI] 2016. 1.2. UDI formats by FDA-Accredited Issuing Agency. http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/UDIIssuingAgencies/UCM489869.pdf .
[JIS X 0212] 1990. Code of the supplementary Japanese Graphic Character set for information interchange.
[NEMA UD3] 2004. Standard for Real-Time Display of Thermal and Mechanical Acoustic Output Indices on Diagnostic Ultrasound Equipment.
[IEEE 754] 2019. IEEE Standard for Floating Point Arithmetic. http://dx.doi.org/10.1109/IEEESTD.2019.8766229 .
[IEEE 1588] 2008. Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. doi:10.1109/IEEESTD.2008.4579760
[IHE ITI TF-2b] 2020. Integrating the Healthcare Enterprise Radiology Technical Framework Volume 2b Transactions Part B – Sections 3.29 – 3.64. http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.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-1x] 2020. Integrating the Healthcare Enterprise Radiology Technical Framework Volume 1x Appendices to Integration Profiles. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol1x.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 .
[IHE RAD TF-2x] 2020. Integrating the Healthcare Enterprise Radiology Technical Framework Volume 2x Appendices to Transactions. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2x.pdf .
[IHE RAD TF-3] 2020. Integrating the Healthcare Enterprise Radiology Technical Framework Volume 3 Cross-Transaction Specifications and Content Specifications. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol3.pdf .
[IHE RAD TF-4] 2020. Integrating the Healthcare Enterprise Radiology Technical Framework Volume 4 National Extensions. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol4.pdf .
[OBJ] 1992. Advanced Visualizer. B1. Object Files (.obj). http://www.cs.utah.edu/~boulos/cs3505/obj_spec.pdf .
[PDF] 1985. Fifth Edition. PDF Reference, version 1.6. http://www.adobe.com/devnet/pdf/pdf_reference_archive.html .
[TIS 620-2533] 1990. Thai Characters Code for Information Interchange. http://www.nectec.or.th/it-standards/std620/std620.html .
[McCollough 2007] Radiology. 2007. 2. 527. “A multi-institutional, multi-manufacturer, international standard for the quantification of coronary artery calcium using cardiac CT”. doi:10.1148/radiol.2432050808
[CSS2] 2011. Cascading Style Sheet (CSS) CSS2 generic font families. http://www.w3.org/TR/REC-CSS2/fonts.html#generic-font-families .
[HPGL] . PCL/PJL Reference PCL5 Printer Language Technical Reference Manual. IIHP 5961-0509. http://www.hp.com/ctg/Manual/bpl13211.pdf .
[AAPM TG 116] July 2009. Report of AAPM Task Group 116 - An Exposure Indicator for Digital Radiography. http://www.aapm.org/pubs/reports/rpt_116.pdf .
[AAPM Report 204] 2011. Report of AAPM Task Group 204 - Size-Specific Dose Estimates (SSDE) in Pediatric and Adult Body CT Examinations. http://www.aapm.org/pubs/reports/RPT_204.pdf .
[AAPM Report 220] September 2014. Report of AAPM Task Group 220 - Use of Water Equivalent Diameter for Calculating Patient Size and Size-Specific Dose Estimates (SSDE) in CT. http://www.aapm.org/pubs/reports/rpt_220.pdf .
[AAPM OR 03] 2005. Assessment of Display Performance for Medical Imaging Systems. http://www.aapm.org/pubs/reports/OR_03.pdf .
[DIN 6868-57] 2001. Image quality assurance in diagnostic X-Ray departments - Acceptance testing for image display devices.
[US 6,272,235] Method and Apparatus for Creating a Virtual Microscope Slide. US Patent. 6,272,235. August 7, 2001.
[Porter and Duff 1984] Computer Graphics. 1984. 3. 253-259. “Compositing Digital Images”. doi:10.1145/800031.808606 http://keithp.com/~keithp/porterduff/p253-porter.pdf .
[Phong 1975] Communications of the ACM. 1975. 6. 311-317. “Illumination for computer generated pictures”. doi:10.1145/360825.360839 http://www.cs.northwestern.edu/~ago820/cs395/Papers/Phong_1975.pdf .
[Poynton 2008] 2008/01/24. Chroma subsampling notation. http://www.poynton.com/PDFs/Chroma_subsampling_notation.pdf .
[POSIX] 2017. POSIX.1-2017 (IEEE Std 1003.1™-2017). http://pubs.opengroup.org/onlinepubs/9699919799/ .
[ZIP] 1989. ZIP File Format Specification. http://www.pkware.com/documents/casestudies/APPNOTE.TXT .
[Chytyk-Praznik 2013] Med Phys. 2013. 3. 031713. “Model-based prediction of portal dose images during patient treatment”. doi:10.1118/1.4792203
For the purposes of this Standard the following definitions apply.
This Part of the Standard is based on the concepts developed in [ISO 7498-1] and [ISO 7498-2] and makes use of the following terms defined in them:
See [ISO 7498-1].
See [ISO 7498-1].
This Part of the Standard makes use of the following terms defined in [ISO/TR 8509]:
See [ISO/TR 8509].
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.4:
This Part of the Standard makes use of the following terms defined in PS3.5:
This Part of the Standard makes use of the following terms defined in PS3.7:
This Part of the Standard makes use of the following terms defined in PS3.8:
A description of the conditions present during data acquisition.
A sequential component of the acquisition portion of a protocol, that contains the parameters necessary to perform a single acquisition. In the case of CT, this would correspond to tube voltage, tube current, rotation time, spatial location, etc. and an Acquisition Protocol Element also corresponds to an [NEMA XR-25] PROTOCOL ELEMENT. In the case of XA, this would correspond to technical factors and control algorithms for the image acquisition, e.g. kVp, mA, pulse width, image quality targets, rotation range, etc.
An affirmative statement or declaration by a specified entity about a specified or implied subject for a specified or implied purpose.
A unique identifier for an Attribute of an Information Object composed of an ordered pair of numbers (a Group Number followed by an Element number).
A Value of the Data Element corresponding to the Attribute of an Information Object.
The Basic Directory Information Object Definition is an abstraction of the information to identify a File-set and facilitate access to the information stored in the files of a File-set based on key medical information.
A model that defines the relationship between the various types of Directory Records that may be used in constructing DICOM Directories.
A set of temporally related Frames acquired at constant or variable Frame rates. This term incorporates the general class of serialography (archaic).
The Attribute Value that consists of an Item of a Code Sequence Attribute.
Attribute that (usually) includes the string "Code Sequence" in the Attribute Name and has a VR of SQ (Sequence of Items). Its purpose is to encode concepts using code values and optional text meanings from Coding Schemes. Section 8.1 through Section 8.8 specify the Attributes of which the Sequence Items (Attribute Sets) of Code Sequence Attributes are constructed.
An Information Object Definition that represents parts of several entities in the DICOM Application Model. Such an IOD includes Attributes that are not inherent in the Real-World Object that the IOD represents but rather are inherent in related Real-World Objects.
An image in which the pixel data was constructed from pixel data of one or more other images (source images).
An Entity-Relationship diagram used to model the relationships between Real-World Objects that are within the area of interest of the DICOM Standard.
An Entity-Relationship diagram that is used to model the relationships between the Information Object Definitions representing classes of Real-World Objects defined by the DICOM Application Model.
A single two-dimensional pixel plane of a Multi-frame Image.
A set of logically related Attributes that are likely to vary together. May be used in Multi-frame IODs to describe parameters that change on a per-frame basis.
That portion of information defined by a Composite IOD that is related to one specific class of Real-World Object. There is a one-to-one correspondence between Information Entities and entities in the DICOM Application Model.
A data abstraction of a class of similar Real-World Objects that defines the nature and Attributes relevant to the class of Real-World Objects represented.
A listing of DICOM Studies, Series, and SOP Instances, and associated metadata, managed by a repository system.
A set of Attributes within an Information Entity or Normalized IOD that are logically related to each other.
An Information Object Definition that represents a single entity in the DICOM Application Model. Such an IOD includes Attributes that are only inherent in the Real-World Object that the IOD represents.
A sequential component of a protocol, consisting of all the parameters necessary to perform that component of the protocol.
A sequential component of the reconstruction portion of a protocol, such as generating CT thin images or multiplanar reformats, or generating XA 2D processed images and/or 3D X-Ray images.
A selected subset of samples within a dataset identified for a particular purpose.
The parameters that select the DICOM Studies that are included in an Inventory. Parameters are specified as matching rules for Attribute Values.
A part of a whole, such as the classification of pixels in an image.
Specialization is the replacement of the Type, Value range and/or description of an Attribute in a general Module of an IOD, by its Type, Value range and/or description defined in a modality-specific Module of an IOD.
The same Attribute may be present in multiple Modules in the same IOD but not specified to be "Specialized".
A sequential component of the storage portion of protocol, such as sending a Series of images to a PACS or an archive or a processing workstation.
This Part of the standard makes use of the following terms defined in [ISO/IEC 2022]:
See [ISO/IEC 2022].
See [ISO/IEC 2022].
See [ISO/IEC 2022].
This Part of the Standard is based on the concepts developed in [IEC 61217] and makes use of the following terms defined in it:
See [IEC 61217].
See [IEC 61217].
See [IEC 61217].
See [IEC 61217].
See [IEC 61217].
See [IEC 61217].
See [IEC 61217].
See [IEC 61217].
This Part of the Standard makes use of the following terms defined in PS3.14:
This Part of the Standard makes use of the following terms defined in PS3.16:
This Part of the Standard makes use of the following terms defined in [ISO 7498-2]:
The definition is "Data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the source and integrity of that unit and protect against forgery e.g., by the recipient."
The definition is "the property that information is not made available or disclosed to unauthorized individuals, entities or processes."
The definition is "the corroboration that the source of data received is as claimed."
The definition is "the property that data has not been altered or destroyed in an unauthorized manner."
The definition is "the generation, storage, distribution, deletion, archiving and application of keys in accordance with a security policy."
This Part of the Standard makes use of the following terms defined in [ECMA 235]:
This Part of the Standard makes use of the following terms defined in PS3.15:
The RCS is the spatial coordinate system in a DICOM Frame of Reference. It is the chosen origin, orientation and spatial scale of an Image IE in a Cartesian space. The RCS is a right-handed Cartesian coordinate system i.e., the vector cross product of a unit vector along the positive x-axis and a unit vector along the positive y-axis is equal to a unit vector along the positive z-axis. The unit length is one millimeter. Typically, the Image IE contains a spatial mapping that specifies the relationship of the image samples to the Cartesian spatial domains of the RCS.
The Corneal Coordinate System is used as the Frame of Reference that establishes the spatial relationship relative to the corneal vertex. The corneal vertex is the point located at the intersection of the patient's line of sight (visual axis) and the outer corneal surface. See Section C.8.30.3.1.4 for further explanation.
A fiducial is some unique feature or landmark suitable as a spatial reference or correlation between similar objects. The fiducial may contribute to the definition of the origin and orientation of a chosen coordinate system. Identifying fiducials in different collections of data is a common means to establish the spatial relationship between similar objects.
A Fiducial Point defines a specific location of a Fiducial. A Fiducial Point is relative to an image or to an RCS.
Also called Multi-Planar Reformatting. A data visualization created by sampling volume data, typically represented by a stack of image planes, that lies in the neighborhood of the intersection of the volume with a plane, curved plane, slab or curved slab.
An MPR where the samples are centered on a single plane intersected with the volume.
A Presentation State that defines a transformation from 3D spatial input data (volume) to 2D spatial output data, with or without affecting other dimensions such as temporal.
The Reference Coordinate System to which inputs to a Volumetric Presentation State are registered and to which Attribute Values of a Volumetric Presentation State are referenced (unless stated otherwise).
A presentation, with two spatial dimensions, of volume data.
This Part of the Standard makes use of the following terms, some of which are defined in PS3.14 or [IEC 62563-1]:
A part of a Display System. A Display Subsystem consists of one Display Device and zero or more other devices (such as controllers). A Display System has one or more Display Subsystems.
See [IEC 62563-1].
This Part of the Standard makes use of the following terms defined in PS3.14:
An alphanumeric identifier issued by the unique device identification system established by the FDA to label and identify devices through distribution and use. See http://www.fda.gov/udi.
This Part of the Standard makes use of the following terms defined in PS3.10:
The following symbols and abbreviations are used in this Part of the Standard.
Comité Européen de Normalisation - Technical Committee 251 - Medical Informatics
Computer-Aided Detection and/or Computer-Aided Diagnosis for chest radiography
International Telecommunications Union - Telecommunications Standardization Sector
Japan Medical Imaging and Radiological Systems Industries Association
Computer-Aided Detection and/or Computer-Aided Diagnosis for Mammography
An entity is used in an Entity-Relationship (E-R) model to represent a Real-World Object, class of Real-World Objects, or DICOM data representation (such as an IOD or Module). An entity is depicted as shown in Figure 5.1-1.
A relationship, which defines how entities are related, is depicted as a diamond within this Part of the DICOM Standard as shown in Figure 5.1-2.
The relationship is read from source to destination entity as indicated by the arrows. The a and b show the source and destination cardinality of the relationship respectively. The following cardinalities are permitted:
(a = 1, b = 1) - one source entity is related to one destination entity
(a = 1, b = 0-n) - one source entity is related to zero or more destination entities
(a = 1, b = 1-n) - one source entity is related to one or more destination entities
(a = 1-n, b = 1) - one or more source entities are related to one destination entity
(a = 1-n, b = 0-n) - one or more source entities are related to zero or more destination entities
(a = 1-n, b = 1-n) - one or more source entities are related to one or more destination entities
In a relationship where (a = 1-n, b = 1-n) the values of the source and destination cardinalities may be different. The value "n" simply denotes one or more.
DICOM has added the use of arrows to the E-R diagramming conventions often used in other literature. This has been done to avoid the possibility of inferring an incorrect relationship that can result from reading a relationship in the reverse order of that intended. For example, a relationship "Cat Catches Mouse" could be read "Mouse Catches Cat" if the arrows were not present.
A relationship may be bi-directional (i.e., the relationship is true in both directions). In such a case, the convention used is arrows pointing toward both the source and the destination entities.
Certain Tables in this Standard describe Sequences of Items by using the symbol: '>'. The symbol '>' precedes the Attribute (or Module) Name of the members of an Item. All marked Attributes (or Modules) belong to the generic description of an Item that may be repeated to form a Sequence of Items. This Sequence of Items is nested in the Attribute (or Module) that precedes in the table the first member marked with a '>'.
The following table describes the "Referenced Series Sequences" Attribute as a Sequence of one or more Items where each Item contains the three Attributes marked by a '>'. The Sequence of Items is nested inside the Value of the Referenced Series Sequence Attribute. The following Attribute (not marked) is not part of the Items of the Sequence.
This notation may be used to create nested hierarchical structures by using '>>' at the second level of nesting and so on.
The Type of the Sequence Attribute defines whether the Sequence Attribute itself must be present, and the Attribute Description of the Sequence Attribute may define whether and how many Items shall be present in the Sequence. The Types of the Attributes of the Data Set included in the Sequence, including any conditionality, are specified within the scope of each Data Set, i.e., for each Item present in the Sequence. See PS3.5.
For describing the number of Items in the Attribute description the following sentences are preferred:
The encoding of empty Sequence Attributes is described in PS3.5.
In a number of cases for Normalized IODs, the Data Element Type and Conditions are defined in the appropriate Service definition in PS3.4, in other cases in the Attribute description in PS3.3. It is not necessary to specify for any Attribute within a Sequence the condition that it is "required if a Sequence Item is present", since this is always implicit, whether or not there are additional requirements.
This section has been retired. See Section 8.
Some tables contain references to Attribute Macros. This convention is used in cases where the same Attributes are used in multiple tables or multiple places in one Module. The reference means that the Attributes of the Attribute Macro shall be included in the Module in place of the row that contains the reference to the Attribute Macro.
In some cases, the Attribute Macro is used in a Sequence (the VR of the Data Element in which the Attribute is encoded is SQ, see PS3.5). When this is done, the reference is preceded by one or more ">" characters. The number of ">" characters indicates the level in the Sequence that all of the Attributes in the Attribute Macro occupy.
There may be specialization of the description of the Attributes in the Attribute Macro. In these cases, this specialization is described in the Description column of the Module.
Following is an example of this convention.
Table 5.4-1 is an example of a Module table using the Attribute Macro convention.
Table 5.4-2 is an example of the Attribute Macro referenced in Table 5.4-1.
The contents of the Example Module Table, if it had not been described with the Example Macro would have been as shown in Table 5.4-3.
Table 5.4-3. Example Module Table Without The Use of An Attribute Macro
In this Module, this Attribute has been specialized to Type 1 as indicated in Table 5.4-1. |
When a Normalized IOD in PS3.3 invokes Modules (e.g., the SOP Common Module) or Attribute Macros that are specified with Data Element Types, those specified Data Element Types and Conditions do not apply. Rather, the Data Element Types and Conditions have to be specified for each Attribute for both SCU and SCP in the appropriate Service definition in PS3.4.
The conventions used for Code Sequences are:
See also “Codes and Controlled Terminology Definitions” in PS3.16 .
In combination with the definition of the Context Group as Extensible or Non-extensible in PS3.16, the conventions in Table 5.6-1 apply.
Table 5.6-1. Conventions for Specification of Context Groups
Any Code may be used if its meaning is applicable to the context of invocation. |
||
Codes in the Context Group may be used. Alternative Codes for the same Concept (i.e., with the same meaning) may be used instead of the Codes in the Context Group, since this can be construed as not using the Baseline Context Group. Codes not in the Context Group may be used as an extension when their meaning is within the scope of that Context Group. I.e., any Code may be used if its meaning is applicable to the context of invocation. See also Section 7.2.3 “Extension of Context Groups” in PS3.16 . |
Non-extensible Context Groups are not used as Baseline Context Groups. |
|
Codes in the Context Group shall be used. Codes not in the Context Group may be used as an extension to the specified Context Group when their meaning is within the scope of that Context Group. See also Section 7.2.3 “Extension of Context Groups” in PS3.16 . |
The DICOM Information Model defines the structure and organization of the information related to the communication of medical images. Figure 6-1 shows the relationships between the major structures of the DICOM Information Model.
An Information Object Definition (IOD) is an object-oriented abstract data model used to specify information about Real-World Objects. An IOD provides communicating Application Entities with a common view of the information to be exchanged.
An IOD does not represent a specific Instance of a Real-World Object, but rather a class of Real-World Objects that share the same properties. An IOD used to generally represent a single class of Real-World Objects is called a Normalized Information Object. An IOD that includes information about related Real-World Objects is called a Composite Information Object.
A Composite IOD is an IOD that represents parts of several entities included in the DICOM Model of the Real World. This Model is introduced in Section 7. Such an IOD includes Attributes that are not inherent in the Real-World Object that the IOD represents but rather are inherent in related Real-World Objects.
These related Real-World Objects provide a complete context for the exchanged information. When an Instance of a Composite IOD is communicated, this entire context is exchanged between Application Entities. Relationships between Composite IOD Instances shall be conveyed in this contextual information.
The Composite IODs are specified in Annex A.
A Normalized IOD is an IOD that generally represents a single entity in the DICOM Model of the Real World.
When an Instance of a Normalized IOD is communicated, the context for that Instance is not actually exchanged. Instead, the context is provided through the use of pointers to related Normalized IOD Instances.
The Normalized IODs are specified in Annex B.
The Attributes of an IOD describe the properties of a Real-World Object Instance. Related Attributes are grouped into Modules that represent a higher level of semantics documented in the Module Specifications found in Annex C.
Attributes are encoded as Data Elements using the rules, the Value Representation and the Value Multiplicity concepts specified in PS3.5. For specific Data Elements, the Value Representation and Value Multiplicity are specified in the Data Dictionary in PS3.6.
When multiple Modules containing the same Attributes(s) are included in an IOD, the Attribute shall be encoded only once into a Data Element.
For on-line communication the DIMSE Services allow a DICOM Application Entity to invoke an operation or notification across a network or a point-to-point interface. DIMSE Services are defined in PS3.7.
For media storage interchange, Media Storage Services allow a DICOM Application Entity to invoke media storage related operations.
These Media Storage Services are discussed in PS3.10.
A DIMSE Service Group specifies one or more operations/notifications defined in PS3.7 that are applicable to an IOD.
DIMSE Service Groups are defined in PS3.4 in the specification of a Service-Object Pair Class.
The SOP Class definitions in PS3.4 contain the rules and semantics that may restrict the use of the services in the DIMSE Service Group and/or the Attributes of the IOD. PS3.10 and PS3.18 contain the rules and semantics that may restrict the Attributes of the IOD or the use of the services in the Media Storage Services and the Web Services respectively.
The selection of SOP Classes is used by Application Entities to establish an agreed set of capabilities to support their interaction for SOP Classes based on DIMSE Services. This negotiation is performed at association establishment time as described in PS3.7. An extended negotiation allows Application Entities to further agree on specific options within a SOP Class.
The SOP Class as defined in the DICOM Information Model is equivalent in ISO/OSI terminology to the Managed Object Class. Readers familiar with object-oriented terminology will recognize the SOP Class operations (and notifications) as comprising the methods of an object class.
DICOM defines two types of SOP Classes, Normalized and Composite. For DIMSE Services, Normalized SOP Classes are defined as the union of a Normalized IOD and a set of DIMSE-N Services, while Composite SOP Classes are defined as the union of a Composite IOD and a set of DIMSE-C Services. Media Storage Services only support Composite IODs and Web Services supports both Normalized and Composite SOP Classes.
SOP Class Specifications play a central role for defining DICOM conformance requirements. It allows DICOM Application Entities to select a well-defined application level subset of the DICOM V3.0 Standard to which they may claim conformance. See PS3.2.
Association establishment is the first phase of communication between peer DICOM compliant Application Entities. The Application Entities shall use association establishment to negotiate which SOP Classes can be exchanged and how this data will be encoded.
Association Negotiation is defined in PS3.7.
A Service Class Specification defines a group of one or more SOP Classes related to a specific function that is to be accomplished by communicating Application Entities. A Service Class Specification also defines rules that allow implementations to state some pre-defined level of conformance to one or more SOP Classes. Applications may conform to SOP Classes as either or both a Service Class User (SCU) or Service Class Provider (SCP).
Service Class Specifications are defined in PS3.4.
Figure 7-1a, Figure 7-1b and Figure 7-3 depict the DICOM view of the Real-World that identifies the relevant Real-World Objects and their relationships within the scope of the DICOM Standard. It provides a common framework to ensure consistency between the various Information Objects defined by the DICOM Standard.
Though typically a single Series is spatially defined by a single Frame of Reference, there may be situations in which a Series contains some Instances without a defined Frame of Reference.
The DICOM Information Model is derived from the DICOM Model of the Real World. The DICOM Information Model presented by Figure 7-2b, Figure 7-2c and Figure 7-2d identify the various IODs specified by this Standard and their relationships. There is not always a one-to-one correspondence between DICOM IODs and Real-World Objects. For example a Composite IOD contains Attributes of multiple real-world objects such as Series, Equipment, Frame of Reference, Study and Patient.
The entities in Figure 7-2b, Figure 7-2c and Figure 7-2d correspond to IODs defined in Annex A, Annex B and Annex C.
Annex A defines Composite IODs (e.g., Images) acquired on a number of Modalities (e.g., CT, MR, NM, US, CR, Secondary Capture). These Composite IODs reference Modules found in Annex C.
Annex B defines Normalized IODs (e.g., Film Session, Print Job) for a number of Service Classes specified in PS3.4. These Normalized IODs reference Module definitions found in Annex C.
For the purpose of the Basic Worklist Management Service Class and the Modality Performed Procedure Step SOP Classes an enhancement of the original DICOM Model of the Real World is made, as depicted in Figure 7-3.
Annex B “Integration of Modality Worklist and Modality Performed Procedure Step in The Original DICOM Standard (Informative)” in PS3.17 discusses the relationship of this extension to the original DICOM model of the real world.
Figure 7-3 is an abstract description of the real world objects invoked in the Modality-IS Interface. It is not to be seen as a database scheme for an implementation.
A Patient is a human or non-human organism receiving, or registered to receive, healthcare services, or the subject of one or more Studies for some other purpose, such as research.
In some circumstances, multiple humans or non-human organisms may be studied simultaneously, and for the purpose of the model are identified as a single Patient. E.g., a mother and one or more fetuses during antepartum obstetric ultrasound, multiple specimens in a single tissue microarray, or a group of multiple research small animals imaged simultaneously.
A Service Episode is a collection of events, aggregated during an interval bounded by start and stop times. A Service Episode is the context in which the treatment or management of an arbitrary subset of a Patient's medical conditions occurs. The definition of the start time, stop time, and included events of a Service Episode is entirely arbitrary; it may include a single outpatient visit or a hospitalization, or extend over significant period of time, e.g., the duration of a pregnancy, or an oncology treatment regimen, or a cardiac episode from infarction through rehabilitation. A Service Episode may involve one or more Healthcare Organizations (administrative entities that authorize Healthcare Providers to provide services within their legal administrative domain, e.g., hospitals, private physician's offices, multispecialty clinics, nursing homes).
A subset of Service Episode, the Visit, is the collection of events that fall under the accountability of a particular Healthcare Organization in a single facility. A Visit may be associated with one or more physical locations (e.g., different rooms, departments, or buildings) within the Healthcare Organization's definition of a facility, with admission and discharge diagnoses and with time boundaries of the visit.
The Visit is a part of the Service Episode. The Service Episode describes several administrative aspects of healthcare, while the Visit is limited to the description of one visit of a Patient to a facility.
In the context of the Modality Worklist SOP Class, the Attributes of the Service Episode are defined in the Visit Modules.
The Attributes for Visit often use the term "admission" for historical reasons, although a visit in an ambulatory clinic does not involve an admission as an in-patient.
An Imaging Service Request is a set of one or more Requested Procedures selected from a list of Procedure Types. An Imaging Service Request is submitted by one authorized imaging service requester to one authorized imaging service provider in the context of one Service Episode. An Imaging Service Request includes pertinent specific and general information. Each instance of an Imaging Service Request carries the information common to one or more Requested Procedures requested at the same moment. An Imaging Service Request may be associated with one or more Visits that occur within the same Service Episode. The existence of an Imaging Service Request will typically result in the creation of one or more Imaging Service Reports and the distribution of Imaging Service Reports to one or more destinations.
In the context of the Modality Worklist the information provided by the Imaging Service Request aims at performing one or more imaging procedures, i.e., at acquiring new images.
An Imaging Service Request is identified by an Accession Number (0008,0050), which is a typically a departmental Information System generated number, but may be generated by a more comprehensive system that spans departments, or enterprises. The scope of uniqueness of an Accession Number (0008,0050) is defined by its issuer, which may be encoded in Issuer of Accession Number Sequence (0008,0051).
A Procedure Type identifies a class of procedures. In the context of imaging services, a Procedure Type is an item in a catalog of imaging procedures that can be requested and reported upon in an imaging service facility. An instance of a Procedure Type typically has a name and one or more other identifiers. A Procedure Type is associated with one or more Procedure Plans.
A Requested Procedure is an instance of a Procedure of a given Procedure Type. An instance of a Requested Procedure includes all of the items of information that are specified by an instance of a Procedure Plan that is selected for the Requested Procedure by the imaging service provider. This Procedure Plan is defined by the imaging service provider on the basis of the Procedure Plan templates associated with the considered Procedure Type. An Imaging Service Request may include requests for several different Requested Procedures. The purpose of this entity is to establish the association between Imaging Service Requests and Procedure Types, to convey the information that belongs to this association and to establish the relationships between Requested Procedures and the other entities that are needed to describe them. A single Requested Procedure of one Procedure Type is the smallest unit of service that can be requested, reported, coded and billed. Performance of one instance of a Requested Procedure is specified by exactly one Procedure Plan. A Requested Procedure leads to one or more Scheduled Procedure Steps involving Protocols as specified by a Procedure Plan. A Requested Procedure may be associated with one or more Visits. A Requested Procedure may involve one or more pieces of equipment.
A Modality Scheduled Procedure Step is an arbitrarily defined scheduled unit of service, that is specified by the Procedure Plan for a Requested Procedure. A Modality Scheduled Procedure Step prescribes a Protocol, which may be identified by one or more protocol codes. A Modality Scheduled Procedure Step involves equipment (e.g., imaging Modality equipment, anesthesia equipment, surgical equipment, transportation equipment), human resources, consumable supplies, location, and time (e.g., start time, stop time, duration). While in the context of imaging services the scheduling of a Modality Scheduled Procedure Step might include only a general designation of imaging Modality that could be satisfied by multiple pieces of the same equipment type, the performance of one instance of a Modality Scheduled Procedure Step involves one and only one piece of imaging Modality equipment.
The performance of a Modality Scheduled Procedure Step may result in the creation of zero or more Modality Performed Procedure Step Instances.
The Procedure Step entity is provided to support management of the logistical aspects of procedures (e.g., materials management, human resources, scheduling). The full definition of the contents of Procedure Steps and protocols according to which they are performed is implementation dependent and is beyond the scope of this Standard.
A Modality Scheduled Procedure Step may contribute to more than one Requested Procedure (e.g., a Modality Scheduled Procedure Step requiring an intravenous iodine contrast injection might be shared by an intravenous pyelogram and a CT examination). However, for billing purposes an Instance of a Modality Scheduled Procedure Step is typically considered to be a part of only one Requested Procedure.
A Procedure Plan is a specification that defines the set of Protocols that must be done in order to perform the Scheduled Procedure Steps of a Requested Procedure. Each Scheduled Procedure Step is performed according to a single Protocol, which may be identified by one or more Protocol Codes and may be described in a Defined Procedure Protocol. The Protocols actually performed during a Procedure Step may be recorded in a Performed Procedure Protocol and may differ from those prescribed in the related Procedure Plan. Audit of actually performed Protocols versus the prescribed Procedure Plan is an important element of quality control.
A Protocol is a specification of actions prescribed by a Procedure Plan to perform a specific Procedure Step. A Scheduled Procedure Step contains only one Protocol, which may be conveyed by one or more Protocol Codes.
A Protocol may be specified by a Defined Procedure Protocol to be used on any appropriate Patient.
A Protocol can be documented, once a Procedure Step has been performed, in a Performed Procedure Protocol.
A Defined Procedure Protocol describes a set of parameters and associated details for the prescribed action. The Defined Procedure Protocol may provide specific values for relevant parameters, or may provide constraints on those parameters (such as an acceptable range) to guide the choice of specific values.
Defined Procedure Protocol is not associated with any particular Patient or Scheduled Procedure Step. A Defined Procedure Protocol may contain parameters specific to a particular model or version of device, or it may be generic in that it only describes parameters common to multiple device models.
A Defined Procedure Protocol may include information such as the clinical purpose, indications, and appropriate device models, intended for selection and management.
A Performed Procedure Protocol encodes the parameter values used. A Performed Procedure Protocol is always associated with a specific Patient and Performed Procedure Step. The Performed Procedure Protocol may reference the Defined Procedure Protocol on which it was based, but does not otherwise record the original constraints and whether or not they were satisfied by the final values as recorded in the Performed Procedure Protocol.
A Performed Procedure Step is an arbitrarily defined unit of service that has actually been performed (not just scheduled). Logically it corresponds to a Scheduled Procedure Step, but real-world conditions may dictate that what is actually performed does not correspond exactly with what was requested or scheduled.
For example, two or more Scheduled Procedure Steps, Requested Procedures or Imaging Service Requests may have been generated by different Referring Physicians but may be satisfied be a single Performed Procedure Step at the discretion of a Performing Physician or Operator. Alternatively, a single Scheduled Procedure Step may need to be satisfied by multiple Performed Procedure Steps on different types or instances of equipment, due to clinical need or failure conditions, or over extended periods of time.
It contains information describing the type of procedure actually performed. This information is represented by the Performed Protocol that may be defined by one or more Protocol Codes.
A Requested Procedure results in the creation of zero or more Performed Procedure Steps.
A Scheduled Procedure Step results in the creation of zero or more Performed Procedure Steps.
The Performed Procedure Step contains information about its state (e.g., in progress, discontinued or completed).
A Modality Performed Procedure Step (MPPS) is a Performed Procedure Step that results from activity (such as the acquisition of images from a Patient or other Imaging Subject) on a Modality.
It contains information describing the performance of a step of an imaging procedure, including data about the performance of the procedure itself, and data for billing and material management.
The Modality Performed Procedure Step contains references to zero or more Series of Images and other Composite SOP Instances that may be created as part of the procedure step. A particular Series is part of only one Modality Performed Procedure Step.
The purpose of the Modality Performed Procedure Step is to report what was performed; it does not imply any storage semantics. While the MPPS represents a unit of service within a workflow, the specification of the workflow itself is beyond the scope of the Standard, and the MPPS does not identify or control any subsequent activities to be performed.
For example, a modality may create both "for processing" images for automated analysis and "for presentation" images for human review from the same acquisition. The Standard does not specify whether the production of these is a single unit of service, or two. A single Modality Performed Procedure Step Instance could list both the "for processing" images and the "for presentation" images, regardless of whether or not both sets of images were stored to the same or different AEs, or indeed were stored at all, since the MPPS is independent of the storage semantics. Alternatively, the modality may treat these two sets of images as two separate units of service, and send two separate MPPS Instances.
A Radiation Dose SR from the irradiation events of an acquisition could be referenced in the same MPPS Instance as that of the acquired images, again irrespective of where such a Radiation Dose Structured Report might be transmitted, if at all. Alternatively, the modality may treat the production of the Radiation Dose SR as a separate unit of service, and report it in a distinct MPPS.
Another example is the case of thin and thick slice CT images acquired from the same acquisition (raw) data. When the reconstruction of both sets of images is prospectively defined and automatically initiated by the protocol selection, then both sets might be referenced from a single MPPS Instance. However, if the reconstruction of one or the other set is performed retrospectively by manual intervention some time after the acquisition MPPS had been completed, the subsequent Instances will necessarily be referenced in a new MPPS Instance, since the acquisition MPPS cannot be modified once completed.
The completion of an MPPS may be a significant event that triggers or enables downstream activity, but it is not the intent to require the modality to be configured to "manage" such activity. The "units of service" that the modality describes in an MPPS, and how the modality relates those Performed Procedure Steps to Scheduled Procedure Steps, are implementation decisions beyond the scope of the Standard. The IHE Radiology Scheduled Workflow Profile [IHE RAD TF-1] provides additional guidance for implementation.
An MPPS may describe Instances that were acquired but that have not been, nor may ever be, stored. For example, a modality may be capable of storing a CT acquisition as multiple single-frame CT Image Storage SOP Instances, as a single multi-frame Enhanced CT Image Storage SOP Instance, or as several Enhanced CT Image Storage SOP Instances that together comprise a Concatenation. An MPPS may describe all three possibilities, even though only one choice may ultimately be stored, perhaps depending on the negotiated capabilities of the storage recipient. Alternatively, separate MPPS Instances could be used for different storage SOP Classes.
The MPPS contains only the Instances that the modality created, not Instances converted and created subsequently in response to a query (e.g., during legacy conversion).
The MPPS is not a substitute for, nor is equivalent to, a Storage Commitment request, nor an Instance Availability Notification.
Retired. See PS3.3-2011.
Retired. See PS3.3-2011.
Retired. See PS3.3-2011.
A Clinical Document is a part of the medical record of a Patient. A Clinical Document is a documentation of clinical observations and services and has the following characteristics:
Persistence - A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements.
Stewardship - A clinical document is maintained by an organization entrusted with its care.
Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.
Context - A clinical document establishes the default context for its contents.
Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.
Clinical Documents may provide significant context for the performance of imaging and related procedures, e.g., patient clinical history, pre-imaging-procedure lab test results, or patient advance medical directives.
Clinical Documents may be associated with Service Episodes, Service Requests, Requested Procedures, or other entities subsidiary to the Patient in the Real-World Model. Such associations are not explicitly modeled for the purposes of the Modality-IS context.
Clinical Documents are one sub-class of the class of healthcare Structured Documents; Structured Documents, in general, are not necessarily related to a Patient. Structured Documents may be used for imaging procedure operational instructions, e.g., in product labeling, Procedure Plans, or patient care plans.
The format and semantics of Structured Documents, including Clinical Documents, are defined outside the scope of the DICOM Standard (e.g., by HL7). DICOM provides the means to reference Structured Documents within the Modality-IS context.
The general class of Structured Documents is not modeled in the Real-World Model; only specific sub-classes, e.g., Clinical Documents, are modeled.
Retired. See PS3.3-2011.
For the purpose of accommodating large sets of Frames in Multi-frame Image SOP Instances the Real-World Entity Relationship Diagram has been extended to describe the relationships of these instances: Concatenation (see Section 7.5.1) and Dimension Organization (see Section 7.5.2). Figure 7.5-1 depicts the additions to Figure 7-1a.
For implementation specific reasons (such as practical limits on the maximum size of an individual SOP Instance) the content of a Multi-frame Image may need to be split into more than one SOP Instance. These SOP Instances together form a Concatenation, which is a group of SOP Instances within a Series that is uniquely identified by Concatenation UID (0020,9161).
The Dimension Organization contains a set of dimensions. A dimension is a set of Attributes that change on a per-frame basis in a manner that is known before the image is acquired, are defined by the generating application and are especially intended for presentation. Other Attributes may also change on a per-frame basis but if they are not present in the Dimension Organization, they are not considered significant as a dimension for organizational purposes.
Receiving applications shall use the order of dimensions for guidance when presenting images if the Multi-frame Dimension Module is present. The first Item of the Dimension Index Sequence shall be the slowest varying index.
See Section C.7.6.17 for an example.
The DICOM Model of the Real World is extended for Clinical Trials and research with the addition of several objects whose relationships to each other and existing DICOM Real World objects are shown in Figure 7.6-1.
Attributes of the Clinical Trial Sponsor, Clinical Trial Protocol, Clinical Trial Subject, and Clinical Trial Site objects are represented in the Clinical Trial Subject Module within the Patient IE. Attributes of the Clinical Trial Time Point object are represented in the Clinical Trial Study Module within the Study IE. The Clinical Trial Coordinating Center Attribute is represented in the Clinical Trial Series Module within the Series IE.
For the purpose of Clinical Trial and Research Information, an extension of the DICOM Model of the Real World is made, as depicted in Figure 7.6-1.
A Clinical Trial Sponsor identifies the agency, group, or institution responsible for conducting and/or funding the clinical trial or research, and for assigning a Protocol Identifier.
A Clinical Trial Protocol identifies the investigational Protocol in which the Subject has been enrolled. The Protocol has a Protocol Identifier and Protocol Name, as well as information related to Ethics Committee, Institutional Review Board (IRB) or Institutional Animal Care and Use Committees (IACUC) approval.
A Clinical Trial Subject identifies the Patient who is enrolled as a Subject in the investigational Protocol.
A Clinical Trial Site identifies the location or institution at which the Subject is treated or evaluated and that is responsible for submitting clinical trial or research data. Images and/or clinical trial data may be collected for a given Subject at alternate institutions, e.g., follow-up scans at a satellite imaging center, but the Clinical Trial Site represents the primary location for Patient management and data submission in the context of a clinical trial or research. In pre-clinical research with small animals, it is typically the single laboratory or shared resource facility.
The Clinical Trial Time Point identifies an imaging Study within the context of a series of longitudinal data acquisitions in an investigational protocol. A Time Point defines a set of Studies that are grouped together as a clinical time point or submission in a clinical trial or for other research.
The Clinical Trial Coordinating Center identifies the institution responsible for coordinating the collection, management, processing, and/or analysis of images and associated data for Subjects enrolled in a clinical trial or research. Within a given Clinical Trial Protocol, there may be multiple Clinical Trial Coordinating Centers, each handling different aspects of the clinical data submitted by the Clinical Trial Sites. In pre-clinical research with small animals, it may be a facility where post processing is performed, separate from the laboratory where the data is acquired.
See Section 7.13.
See Section 7.13.
The DICOM Model of the Real World is extended for Specimens with the addition of several objects whose relationships to each other and existing DICOM Real World objects are shown in Figure 7.9-1.
Attributes of the Specimen, Container, Component and Preparation Step objects are represented in the Specimen Module within the Image IODs.
A physical object (or a collection of objects) is a specimen when the laboratory considers it a single discrete, uniquely identified unit that is the subject of one or more steps in the laboratory (diagnostic) workflow.
Specimen containers (or just "containers") play an important role in laboratory (diagnostic) processes. In most, but not all, process steps, specimens are held in containers, and a container often carries its specimen's ID. Sometimes the container becomes intimately involved with the specimen (e.g., a paraffin block), and in some situations (such as examining tissue under the microscope) the container (the slide and coverslip) become part of the optical path.
Containers are often made up of components. For example, a "slide" is container that is made up of the glass slide, the coverslip and the "glue" the binds them together.
See Section 7.13.
The DICOM Model of the Real World is extended with the addition of a Unified Procedure Step object whose relationship to existing DICOM Real World objects is shown in Figure 7.11-1.
A Unified Procedure Step (UPS) represents an arbitrary unit of service. Unified Procedure Steps are generally scheduled in response to a Requested Procedure, although a UPS may be triggered by other events, such as a scheduled calibration, completion of prior work in a pipeline, etc.
The Unified Procedure Step (UPS) unifies the details of the procedure step that has been requested, the progress details during performance, and the details of the procedure step actually performed. The details can describe the specific service activity, the subject and/or data acted on, the originator and context of the request, the human/equipment/application resources involved, the priority, date, time and location of the activity, and references to resulting output data.
Normally the details about the activity as performed correspond to the details of the activity as requested, however real-world conditions may dictate that what is actually performed does not correspond exactly with what was requested or scheduled.
The DICOM Model of the Real World is extended for Display System with the addition of an entity that is separate from the rest of the DICOM Real World objects, as shown in Figure 7.12-1. A Display System is not associated with any specific objects in the existing DICOM Information model, because it is not associated with a specific Patient. One Display System object is included in a Display System IOD.
A Display Subsystem represents the target of a Display QA task such as calibration. For example, a PACS reading station with one color controller driving one display, and 4 grayscale displays each driven by two controllers is modeled as 5 Display Subsystems, each of which can be the target of a Display QA task. A tablet represents one Display System with a Display Device but no externally exposed controller. Although Display Subsystem may include components beyond the Display Device, this Model focuses on the Display Device only.
Figure 7.12-2 illustrates how the composition of Display Subsystems is represented in the Display System IOD.
The DICOM Model of the Real World is extended for a variety of non-patient-related information with the specification of entities that are generally separate from the rest of the DICOM Real World Information Model. These information entities are not associated with a specific Patient. While there may be entity relationships, there is no hierarchy applied to these entities.
A Hanging Protocol Information Entity specifies the viewing preferences of a specific user or group, for a specific type of Study (Modality, Anatomy, Laterality combination, and optionally Procedure, and/or Reason). A Hanging Protocol definition includes descriptors that identify the Hanging Protocol, the creator, the type of Study it addresses, the type of image sets to display, the intended display environment, and the intended layout for the screen(s).
The Hanging Protocol IE does not have any relationships with other Information Entities. See Figure 7.13-1.
A Color Palette Information Entity specifies a color palette suitable for application to an image with a single channel of information (grayscale) to render it in color, i.e., pseudo-coloring.
The Color Palette IE may be referenced by Image or Presentation State Information Entities. See Figure 7.13-2.
The Color Palette IOD instantiates the Color Palette IE only.
An Implant Template Information Entity specifies a 2D- and/or 3D-template representing a physical implant. The IE specifies mechanisms for implant assembly, i.e., the rigid connection of two or more implants.
The Implant Template IE may be related to a Surface IE (see Section A.1.2.18) or to an Encapsulated Document IE (see Section A.1.2.16) for the specification of the 2D- or 3D-template.
The Implant Template IE may be related to a Frame of Reference IE (see Section A.1.2.5) to support registration of the template with Patient anatomical landmarks in a separate Frame of Reference.
The Implant Template IE may be related to an Implant Assembly Template IE for the specification of multi-part assemblies. The Implant Template IE may be related to an Implant Template Group IE for shared management of a set of templates.
See Figure 7.13-3.
An Implant Assembly Template Information Entity specifies how to combine several implants to fulfill a certain purpose.
The Implant Assembly Template IE is related to Implant Template IEs.
An Implant Template Group Information Entity specifies a set of Implant Templates for shared specification and management. It facilitates browsing through a set of similar implants by providing similar matching coordinates, and by ordering the referenced templates by dimensional size or similar attributes.
The Implant Template Group IE is related to Implant Template IEs.
The DICOM Model of the Real World is extended with the addition of Defined Procedure Protocol and Performed Procedure Protocol objects whose relationship to existing DICOM Real World objects is shown in Figure 7.13.4-1.
Note that the information in the Equipment IE describes the equipment that created the Instance. The information in the Protocol Parameters may describe the equipment on which the protocol is intended to be executed which may or may not be the same as the equipment that created the Instance.
Figure 7.13.6-1 shows the E-R diagram for the Inventory Information Model. The Inventory Information Entity provides an Inventory of Studies, and their component Series and SOP Instances, managed by a repository (such as a Picture Archiving and Communication System - PACS). The Inventory Information Model includes contextual information about each Study through the Patient and Imaging Service Request IEs. It includes information on the stored SOP Instances, including access mechanisms supported by the repository.
This information model is similar to the Study Root Query/Retrieve Information Model (see Section C.6.2.1 in PS3.4).
There is a potentially complex relationship between the Study and Imaging Service Requests in the real world (e.g., see [IHE RAD TF-2] Section 4.6.4.1.2.3 Relationship between Scheduled and Performed Procedure Steps). However, the Inventory Information Model follows the basic Study Information Model and supports only a single Accession Number representing an Imaging Service Request (see Section C.7.2.1). Note that if a Study has multiple associated Imaging Service Requests, the request Attributes may be encoded at the Series level.
For the purpose of RT Second Generation SOP Classes the DICOM Model of the Real-World is described in this section. This subset of the real-world model covers the requirements for transferring information about planned and performed radiotherapeutic treatments and associated data.
Figure 7.14-1 describes the most important elements involved in the radiotherapy domain in DICOM.
IODs which contain a representation of Volumes, Surfaces, Lines, Points can be annotated by an RT Segment Annotation.
For better readability the diagram only contains the most important relationships, e.g. all objects have a relation to the Patient, but not all of these relationships are part of this diagram.
The RT Course is a top-level entity that represents a radiotherapy treatment course, usually specified in one or more RT Prescriptions, generally for a defined tumor or group of tumors. A patient undergoing treatments of radiotherapy has one treatment course at a time. The RT Course may consist of several RT Treatment Phases (possibly with breaks of treatment in between them). Each treatment phase may consist of one or more RT Treatment Sessions. An RT Treatment Session is delivered in one patient visit to a venue with a treatment machine and will typically deliver a fraction of one or more RT Radiation Sets. A new RT Course is administered, when the patient is treated for a re-occurrence or a new tumor site - typically after a period of a year or more after the previous RT Course has been finished.
The RT Course can be thought of as a container collecting all major objects which are relevant to this course. The RT Physician Intent and RT Radiation Sets reference other companion objects necessary to prepare, conduct and review the treatment. Timing information (start dates and phasing of treatment, breaks etc.) are also part of the RT Course information. Additionally it contains information of the ongoing status in treatment planning and delivery. The RT Course is a dynamic object that represents the current status of the patient"s treatment.
The RT Course may also include information about previously conducted treatments by referencing previous RT Course objects or by directly recording the information in Attributes.
The RT Physician Intent describes how the physician wishes to achieve curative or palliative therapy. This information includes, but is not limited to the use of external radiation therapy or brachytherapy, total and fractional doses and fractionation schemes, treatment sites, Dosimetric Objectives, envisioned treatment technique, beam energy or isotopes, and patient setup notes.
The Conceptual Volume is a reference to a certain anatomical region or point. Conceptual Volumes may or may not have a representation in segmented images. In most cases they will be related to one or more volumetric representations in various image sets taken at different times.
For example, during a radiotherapy course at the time of prescription, physicians specify regions to which dose is prescribed. Subsequently these regions are referenced in other objects in order to track calculated and delivered dose in the course of treatment. This referencing capability is provided by the Conceptual Volume.
The RT Segment Annotation annotates segmented regions defined in other SOP Instances with radiotherapy-specific information about the role and RT-specific types of the regions (e.g. clinical target volume, organ at risk, bolus), and other information such as density definitions. An RT Segment Annotation SOP Instance may reference any geometric general-purpose representation entity defined by DICOM.
An RT Radiation Set is a collection of RT Radiations. An RT Radiation Set defines a Radiotherapy treatment fraction, which will be applied one or more times. The RT Radiation Set is delivered by delivering the radiation of all referenced RT Radiations.
Parallel and intermittent fractionation schemes, e.g. treatment of several target sites with different timing schemes, are represented by multiple RT Radiation Sets.
An RT Radiation is a contiguous set of Control Points, describing machine and positioning parameters to be applied during treatment delivery. An RT Radiation describes one portion of an RT Radiation Set and represents an single-fraction delivery of therapeutic radiation intended to be delivered in an indivisible manner. An RT Radiation is typically referred to in end-user terminology as a beam (in external beam treatment) or a catheter (in brachytherapy).
The RT Radiation Record records actual treatment parameters that have been applied during the delivery of an RT Radiation in the context of a specific fraction. Typically, those parameters are the same as those described within an RT Radiation, but may differ due to therapist decisions and/or circumstances of the delivery technology and/or for various other reasons.
An RT Course may be divided into multiple RT Treatment Phases. Each RT Treatment Phase represents a period of time during which a defined number of RT Treatment Fractions are delivered by RT Radiation Sets in order to reach a specific treatment goal (see Section 7.14.9 and Section 7.14.10).
An RT Treatment Phase also defines the chronological relationship between RT Radiation Sets that are concurrently and/or subsequently treated.
Fractionation describes the splitting of a course of therapeutic radiation delivery into multiple sessions. Each session may consist of the delivery of one or more RT Radiation Sets. The temporal pattern of session is called a fractionation scheme.
Further descriptions and examples of this such schemes can seen in Section 7.14.10.
An RT Treatment Session is a collection of RT treatment events that are performed in a contiguous manner without any break in-between (other than time needed for required preparations) during a single Visit. It is bound by the time period between the patient entering the treatment room and leaving the treatment room. In a treatment session one or more RT Radiation Sets (RSet in Figure 7.14-2) may be treated, each one instructed by an RT Radiation Set Delivery Instruction. An RT Treatment Session may also include imaging. A group of radiation deliveries that are separated by an intentional delay to accommodate radiobiological recovery effects are considered separate Treatment Sessions.
The Treatment Session UID (300A,0700), if present, uniquely identifies a RT Treatment Session.
Each treatment of an RT Radiation Set is labeled as an RT Treatment Fraction (often abbreviated as Fx) with a fraction number starting with 1 at the first RT Treatment Session in which the RT Radiation Set is delivered, incremented by 1 at each subsequent treatment session.
An RT Treatment Fraction is the delivery of a portion of the total dose (whose delivery is defined by an RT Radiation Set) which has been divided equally into smaller doses to be delivered over a period of time (e.g. daily for 4-6 weeks). In radiotherapy, this division of dose over a period of time is known as dose fractionation.
Partial treatments annotate RT Treatment Fractions, that are not completely performed for any reason (e.g. patient sickness, delivery device breakdown). The remainder of the RT Treatment Fraction is usually delivered at a later time. This remaining portion has the same fraction number as the one of the Partial Treatment Fraction. Further treatments will start a new RT Treatment Fraction with an incremented fraction number.
In Figure 7.14-3, the shaded areas of each Radiation Set represent the portion where dose is actually delivered. Partially shaded Radiation Sets therefore represents a partial treatment.
The Dosimetric Objective Macro specifies an intended goal to be used in the definition of the dosimetric plan for plan optimization etc. Dosimetric Objectives may define limits which affect the dose, such as dose volume constraints, minimum or maximum dose, treatment time or MU limits, and radiobiologic effects.
The primary method of incorporating coded entry data in DICOM IODs is the Code Sequence Attribute. Code Sequence Attributes are encoded as a Sequence of Items using a Macro that is described in this section. These Attributes typically include the string "Code Sequence" in the Attribute Name. Their purpose is to encode terms by using codes from Coding Schemes.
In this Standard, Code Sequence Attributes are defined for a variety of concepts, for example: Primary Anatomic Structure Sequence (0008,2228) and other Attributes to describe anatomy; and Intervention Drug Code Sequence (0018,0029), to document administration of drugs that have special significance in Imaging Procedures.
Each Item of a Code Sequence Attribute contains the triplet of Coding Scheme Designator (0008,0102), the Code Value (0008,0100) (or Long Code Value (0008,0119) or URN Code Value (0008,0120)), and Code Meaning (0008,0104). Other optional and conditional Attributes may also be present.
For any particular Code Sequence Attributes, the range of codes that may be used for that Attribute (the Value Set) may be suggested or constrained by specification of a Context Group. The Module or Template in which the Attribute is used will specify whether or not the context group is baseline or defined. A Baseline Context Group lists codes for terms that are suggested and may be used, but are not required to be used. A Defined Context Group lists codes for terms that shall be used if the term is used.
Context Groups are defined in a Mapping Resource, such as the DICOM Content Mapping Resource (DCMR) specified in PS3.16. Context Groups consist of lists of contextually related coded concepts, including Code Value (0008,0100) (or Long Code Value (0008,0119) or URN Code Value (0008,0120)) and Coding Scheme Designator (0008,0102). Each concept is unique within the Context Group and identified by its Code Value (0008,0100) (or Long Code Value (0008,0119) or URN Code Value (0008,0120)) and Coding Scheme Designator (0008,0102). The Context Group specification identifies whether it is extensible, i.e., whether it may be modified in an Application to use additional terms (see PS3.16). Whether a Context Group is used as a Baseline or Defined Context Group is defined not in the mapping resource, but rather in the Template or Module in which the Code Sequence Attribute is used.
Context Groups are identified by labels referred to as Context Identifiers (CID). Formally, the Context Identifier (0008,010F) specifies the context of use, not the specific list of coded values selected for that context of use in the Context Group. The set of values specified in the Standard for a particular context may change over time, and set of values used by an Application Entity for a particular context may include a local or private extension beyond the Standard value set.
A specific set of coded values used by an Application Entity is therefore identified by the Mapping Resource (0008,0105), plus the Context Identifier (0008,010F), plus the Context Group Version (0008,0106), plus the identifiers for any private extension.
The use by an Application Entity of coded terms not in the Standard specified Context Group does not require the explicit identification of a private extension. The Application Entity is then the implicit source of the extension.
For the purpose of harmonization with HL7 vocabulary concepts, Context Groups are equivalent to HL7 Value Sets.
Code Value (0008,0100) is an identifier that is unambiguous within the Coding Scheme denoted by Coding Scheme Designator (0008,0102) and Coding Scheme Version (0008,0103).
The Long Code Value (0008,0119) or URN Code Value (0008,0120) is only used for codes that exceed the 16 character size limit of Code Value (0008,0100). If the length of the code value exceeds 16, the Code Value (0008,0100) shall not be present. If the length of the code value is 16 characters or less, the Code Value (0008,0100) shall contain the code and neither Long Code Value (0008,0119) nor URN Code Value (0008,0120) shall be present. The URN Code Value (0008,0120) shall be used for codes that are represented using URN or URL notation. The Long Code Value (0008,0119) shall be used for codes that are represented using other notations and that exceed 16 characters in length.
The Attribute Coding Scheme Designator (0008,0102) identifies the Coding Scheme in which the code for a term is defined. Standard Coding Scheme designators used in DICOM information interchange are listed in PS3.16. Other Coding Scheme designators, for both private and public Coding Schemes, may be used, in accordance with PS3.16. Further identification of the Coding Scheme designators used in a SOP Instance may be provided in the Coding Scheme Identification Sequence (0008,0110) (see Section C.12.1).
Typical Coding Schemes used in DICOM include "DCM" for DICOM defined codes, "SCT" for SNOMED CT, and "LN" for LOINC. See Annex 8 “Coding Schemes” in PS3.16.
Coding Scheme designators beginning with "99" and the Coding Scheme designator "L" are defined in HL7 V2 to be private or local Coding Schemes.
Most IODs that define the use of coded terms provide for the use of private codes and Coding Schemes through replacement of Baseline Context Groups or extension of Defined Context Groups. Systems supporting such private code use must provide a mechanism for the configuration of sets of Coding Scheme Designator (0008,0102), Code Value (0008,0100) (or Long Code Value (0008,0119) or URN Code Value (0008,0120)), and Code Meaning (0008,0104) to support interoperation of the private codes with other systems.
It is highly recommended that local or non-standard Coding Schemes be identified in the Coding Scheme Identification Sequence (0008,0110). Documents or machine readable representations of the Coding Scheme (e.g., CSV or OWL files) can be linked to via a Coding Scheme URL (0008,010E). For appropriate values, see Table 8-1 “Coding Schemes” in PS3.16 .
URN and URL codes usually lack a Coding Scheme Designator (0008,0102).
The Attribute Coding Scheme Version (0008,0103) may be used to identify the version of a Coding Scheme if necessary to resolve ambiguity in Code Value (0008,0100), Long Code Value (0008,0119) or URN Code Value (0008,0120). Coding Scheme Version (0008,0103) is not required for backward-compatible revisions of a Coding Scheme, as the Coding Scheme Designator (0008,0102) identifies the Coding Scheme as a whole as currently published by the responsible organization.
See PS3.16 for a discussion of SNOMED Coding Scheme Designators 99SDM, SNM3, SRT and SCT.
ICD-10, for example, is not a backward-compatible revision of ICD-9, and hence it has a different Coding Scheme Designator, not simply a different Coding Scheme Version.
Code Meaning (0008,0104) is text that has meaning to a human and conveys the meaning of the term defined by the combination of Code Value (0008,0100) (or Long Code Value (0008,0119) or URN Code Value (0008,0120)), and Coding Scheme Designator (0008,0102). Though such a meaning can be "looked up" in the dictionary for the Coding Scheme, it is encoded for the convenience of applications that do not have access to such a dictionary.
It should be noted that for a particular Coding Scheme Designator (0008,0102) and Code Value (0008,0100) or Long Code Value (0008,0119), or URN Code Value (0008,0120), several alternative values for Code Meaning (0008,0104) may be defined. These may be synonyms in the same language or translations of the Coding Scheme into other languages. Hence the Value of Code Meaning (0008,0104) shall never be used as a key, index or decision value, rather the combination of Coding Scheme Designator (0008,0102) and Code Value (0008,0100), Long Code Value (0008,0119), or URN Code Value (0008,0120) may be used. Code Meaning (0008,0104) is a purely annotative, descriptive Attribute.
This does not imply that Code Meaning (0008,0104) can be filled with arbitrary free text. Available values from the Coding Scheme or translation in the chosen language shall be used.
The Value of Mapping Resource (0008,0105) denotes the message/terminology Mapping Resource that specifies the Context Group that specifies the Value Set. The Defined Terms for the Value of Mapping Resource (0008,0105) shall be:
PS3.16 specifies the DICOM Content Mapping Resource (DCMR).
Unless otherwise specified, the DCMR is the source of all Context Groups and Templates specified in this Standard.
Mapping Resources may be uniquely identified by Mapping Resource UID (0008,0118).
Private Mapping Resources (those not listed amongst the Defined Terms in this section), may be identified by the prefix "99".
Mapping Resource Name (0008,0122) may contain the name of the Mapping Resource. The value may e.g., denote the Institution or organization that has specified the Value Set.
Context Group Version (0008,0106) conveys the version of the Context Group identified by Context Identifier (0008,010F). This Attribute uses VR DT, but for Context Groups defined in PS3.16 the precision of Context Group Version (0008,0106) is limited to the day, and the time zone offset is not used.
The Value of Context Identifier (0008,010F) identifies the Context Group defined by Mapping Resource (0008,0105) from which the Values of Code Value (0008,0100) (or Long Code Value (0008,0119) or URN Code Value (0008,0120)) and Code Meaning (0008,0104) were selected, or to which Code Value (0008,0100) (or Long Code Value (0008,0119) or URN Code Value (0008,0120)) and Code Meaning (0008,0104) have been added as a private Context Group extension (see Section 8.7). The Context Identifier (0008,010F) uses VR CS, and for Context Groups defined in PS3.16 the Value shall be the Context Group Identifier as a string of digits without leading zeros, and does not include the string "CID".
The Value of Context UID (0008,0117) uniquely identifies the Context Group. See PS3.6.
Context Group Extension Flag (0008,010B) may be used to designate a pair of Code Value (0008,0100) (or Long Code Value (0008,0119) or URN Code Value (0008,0120)) and Code Meaning (0008,0104) as a selection from a private extension of a Context Group. If the Context Group Extension Flag (0008,010B) is present, and has a Value of "Y", Context Group Extension Creator UID (0008,010D) shall be used to identify the person or organization who created the extension to the Context Group. Context Group Local Version (0008,0107) conveys an implementation-specific private version DateTime of a Context Group that contains private extensions.
These Attributes provide the means for implementations to extend code sets conveniently, while preserving referential integrity with respect to the original Context Group Version (0008,0106).
The locally-defined (private) Value of Context Group Local Version (0008,0107) typically would be a more recent date than the standard Value of Context Group Version (0008,0106) specified in the standard message/terminology Mapping Resource that defines the Context Group.
Table 8.8-1 specifies the default set of Attributes encapsulated in the Items of Code Sequence Attributes. These Attributes comprise the Code Sequence Macro.
The instruction "Include Table 8.8-1 “Code Sequence Macro Attributes” " may be used in an IOD as a concise way to indicate that the Attributes of Table 8.8-1 are included in the specification of the Attribute Set of a Sequence of Items. Additional constraints on the Code Sequence Data Element (such as a Context Group that defines the value set) may be appended to the "Include Table 8.8-1 “Code Sequence Macro Attributes” " instruction.
The default specifications of this Section are overridden within the scope of a Sequence Item or Code Sequence Attribute or IOD by corresponding specifications defined within the scope of that Sequence Item or Code Sequence Attribute or IOD. Additional Attributes may also be specified by the instantiation of the Macro.
The Basic Coded Entry Attributes fully define a Coded Entry. If it is desired to convey the list from which a code has been chosen, then the optional Enhanced Encoding Mode Attributes may also be present.
Table 8.8-1a. Basic Code Sequence Macro Attributes
The identifier of the Coded Entry. See Section 8.1. Shall be present if the length of the code value is 16 characters or less, and the code value is not a URN or URL. |
|||
The identifier of the Coding Scheme in which the Coded Entry is defined. See Section 8.2. Shall be present if Code Value (0008,0100) or Long Code Value (0008,0119) is present. May be present otherwise. |
|||
An identifier of the version of the Coding Scheme if necessary to resolve ambiguity. See Section 8.2. Required if the Value of Coding Scheme Designator (0008,0102) is present and is not sufficient to identify the Code Value (0008,0100) or Long Code Value (0008,0119) unambiguously. Shall not be present if Coding Scheme Designator (0008,0102) is absent. May be present otherwise. |
|||
Text that conveys the meaning of the Coded Entry. See Section 8.3. |
|||
The identifier of the Coded Entry. See Section 8.1. Shall be present if Code Value (0008,0100) is not present and the Code Value is not a URN or URL. |
|||
The identifier of the Coded Entry. See Section 8.1. Shall be present if Code Value (0008,0100) is not present and the Code Value is a URN or URL. |
Table 8.8-1b. Enhanced Code Sequence Macro Attributes
The identifier of the Context Group from which the Coded Entry was selected. See Section 8.6. |
|||
The unique identifier of the Context Group from which the Coded Entry was selected. See Section 8.6. |
|||
The identifier of the Mapping Resource that defines the Context Group from which Coded Entry was selected. See Section 8.4. Required if Context Identifier (0008,010F) is present. |
|||
The unique identifier of the Mapping Resource that defines the Context Group from which Coded Entry was selected. NoteThe unique identifier for the DICOM Content Mapping Resource "DCMR" is defined in PS3.6. |
|||
The name of the Mapping Resource that defines the Context Group from which Coded Entry was selected. See Section 8.4. |
|||
The identifier of the version of the Context Group from which the Coded Entry was selected. See Section 8.5. |
|||
Indicates whether the triplet of Code Value (0008,0100) (or Long Code Value (0008,0119) or URN Code Value (0008,0120))/Coding Scheme Designator (0008,0102)/Code Meaning (0008,0104) is selected from a private extension of the Context Group identified in Context Identifier (0008,010F). See Section 8.7. |
|||
An implementation-specific version of a Context Group that contains private extensions. See Section 8.7. Required if the Value of Context Group Extension Flag (0008,010B) is "Y". |
|||
Identifies the person or organization who created an extension to the Context Group. See Section 8.7. Required if the Value of Context Group Extension Flag (0008,010B) is "Y". |
Table 8.8-1. Code Sequence Macro Attributes
Include Table 8.8-1a |
|||
Codes that are considered equivalent by the creating system. One or more Items are permitted in this Sequence. See Section 8.9. |
|||
>Include Table 8.8-1a |
|||
>Include Table 8.8-1b |
|||
Include Table 8.8-1b |
The Equivalent Code Sequence (0008,0121) may optionally be used to convey different codes for the same concept.
Equivalence is defined as having the same or similar meaning, and requires that equivalent concepts do not include different aspects, properties, features, characteristics, or parameters.
E.g., the SNOMED and FMA codes for a structure of the breast, (76752008, SCT, "Breast") and (57983, FMA, "Breast") would be considered equivalent. Neither would be equivalent to concepts that pre-coordinated other aspects such as laterality, e.g., (80248007, SCT, "Left breast"), or entire body organ, e.g., (181131000, SCT, "Entire breast").
Some scenarios in which it is helpful for the creating system to send equivalent codes include:
when different representations of the same concept are present in a standard Coding Scheme, such as the SNOMED-CT and SNOMED-RT and CTV3 style identifiers,
when the same concept is present in different standard Coding Schemes, but considered by the creating system to be synonymous, such as anatomical concepts from SNOMED and FMA, and
when the same concept is present in a local as well as a standard Coding Scheme, but considered by the creating system to be synonymous, such as a local private procedure code and the same concept in LOINC or SNOMED or RADLEX.
The Table 8.8-1b may be used to identify a Context Group from which the codes were selected, such as for a particular cross-institutional, cross-application context for trials, research and knowledge-based applications.
An example of a long SNOMED CT code encoding as an Item in a Sequence:
SCT:621566751000087104 is not included in the SNOMED CT DICOM Subset and is not present in the SNOMED CT INT release. It is from the Canadian National Extension and is used here only as an example.
An example of a short SNOMED CT with equivalent SNOMED SRT and CTV3 (Read) codes as an Item in a Sequence:
Dimeglumine gadopentetate 469.01mg/mL inj soln 15mL pfld syr |
||||
Dimeglumine gadopentetate 469.01mg/mL inj soln 15mL pfld syr |
||||
Dimeglumine gadopentetate 469.01mg/mL inj soln 15mL pfld syr |
||||
As this Standard and external Coding Schemes are maintained, the codes specified as values for Code Sequence Attributes and in Conditions may change. The previous codes are considered Retired but implementations may continue to send them and receivers will be expected to be able to continue to recognize the Retired codes, including the Code Value (0008,0100) and Coding Scheme Designator (0008,0102) Values, even if the current Standard does not publish them.
A notable example is the change throughout the Standard from using "SNOMED-RT style" code values with a Coding Scheme Designator (0008,0102) of "SRT", "SNM3" or "99SDM", to the use of SNOMED CT numeric code values with a Coding Scheme Designator (0008,0102) of "SCT". Those retired codes may be found in PS3.3-2019a. A mapping of retired to new SNOMED code values is found in Annex O “SNOMED Concept ID to SNOMED ID Mapping” in PS3.16.
Section 9 was defined in a previous release of the DICOM Standard (see PS3.3-2004). The Section is now retired, and its contents have been consolidated into Section C.18.8.
This Macro may be invoked to specify a coded representation of a person such as a healthcare worker, and the organization to which they are responsible.
This Macro is typically invoked within a Sequence Item used to identify an individual such as a physician or a device operator.
The free-text name of the individual is not included in this Macro since there are already widely used specific Attributes to hold such values.
No Baseline, Defined or Enumerated CIDs are defined nor is any particular Coding Scheme specified. In practice, workers are usually identified by using a locally or nationally specific Coding Scheme. For example, a local Coding Scheme Designator might be used and the individual's internal hospital ID number user in Code Value.
The organization is specified by either a coded Sequence or a free text name but not both. A Baseline CID of standard organizations is provided for the purpose of identifying standard organizations responsible for creation of Well Known Instances.
Table 10-1. Person Identification Macro Attributes
A Content Item is a flexible means of encoding attribute identifiers and attribute values using the Code Sequence Macro (see Section 8) for coded terminology defined by a Coding Scheme. The Content Item provides a name-value pair, i.e., a Concept Name, encoded as a Code Sequence, and a Concept Value. The Concept Value may be encoded by any of a set of generic Attributes, as specified by a Value Type, including text, personal name, numeric, and coded concept (Code Sequence) Values.
Comparing a Content Item to a native DICOM Data Element, the Concept Name Code Sequence (0040,A043) corresponds to the Data Element Tag and Attribute Name, the Value Type to the Value Representation, and the Concept Value to the Data Element Value Field. See PS3.5.
The IMAGE Value Type of this Macro does not include the Type 3 Attributes of the IMAGE Value Type defined in Section C.17.3, as they are not required for Acquisition Context or Protocol Context Content Items.
Specific uses of the Content Item may invoke the Content Item Macro defined in this Section, the Document Content Macro of Section C.17.3, or another similar construct. An invocation of the Content Item Macro may constrain the allowed Values of Value Type (0040,A040).
The NUMERIC Value Type of this Macro differs from the NUM Value Type defined in Section C.17.3, since the encoding of the Concept Value is different.
The Value Type uses Enumerated Values so as to assure that non-standard Value Types are not used, and to prevent the nefarious use, for example, of a CONTAINER Value Type in an SR-like manner to create nested content, which is not the intent.
Some invocations of this Macro may use the Content Item Modifier Sequence (0040,0441) to achieve a single level of "nesting". That Attribute is not included in this Macro itself, to prevent recursive inclusion.
See Section 5.4 for the meaning of the Type column in this Macro when applied to Normalized IODs.
Table 10-2. Content Item Macro Attributes
The date and time on which this Item was completed. For the purpose of recording measurements or logging events, completion time is defined as the ending time of data acquisition of the measurement, or the ending time of occurrence of the event. |
|||
The date and time on which this Item was started. For the purpose of recording measurements or logging events, start time is defined as the ending time of data acquisition of the measurement, or the start time of occurrence of the event. |
|||
Coded concept value of this name-value Item. |
|||
Numeric value for this name-value Item. Only a single Value shall be present. |
|||
The floating point representation of Numeric Value (0040,A30A). The same number of Values as Numeric Value (0040,A30A) shall be present. Required if Numeric Value (0040,A30A) has insufficient precision to represent the value as a string. May be present otherwise. |
|||
The integer numerator of a rational representation of Numeric Value (0040,A30A), encoded as a signed integer value. The same number of Values as Numeric Value (0040,A30A) shall be present. Required if Numeric Value (0040,A30A) has insufficient precision to represent a rational value as a string. May be present otherwise. |
|||
The integer denominator of a rational representation of Numeric Value (0040,A30A), encoded as a non-zero unsigned integer value. The same number of Values as Numeric Value (0040,A30A) shall be present. Required if Rational Numerator Value (0040,A162) is present. |
|||
Units of measurement for a numeric value in this name-value Item. |
|||
Composite SOP Instance Reference value for this name-value Item. Only a single Item shall be included in this Sequence. Required if Value Type (0040,A040) is COMPOSITE or IMAGE or WAVEFORM. |
|||
>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
Identifies the Frame numbers within the Referenced SOP Instance to which the reference applies. The first Frame shall be denoted as Frame number 1. Required if the Referenced SOP Instance is a Multi-frame Image and the reference does not apply to all Frames, and Referenced Segment Number (0062,000B) is not present. |
|||
Identifies the segments to which the reference applies identified by Segment Number (0062,0004). Required if the Referenced SOP Instance is a Segmentation or Surface Segmentation and the reference does not apply to all segments and Referenced Frame Number (0008,1160) is not present. |
|||
List of channels in Waveform to which the reference applies. See Section C.18.5.1.1. Required if the Referenced SOP Instance is a Waveform that contains multiple Channels and the reference does not apply to all Channels of all Multiplex Groups. |
Content Item with Modifiers is a means of describing structured content which needs a Content Item with single optional level of modifiers, i.e. a two-level structure of Content Items. An invocation of the Content Item with Modifiers Macro will usually specify the allowed values using a Protocol Context Template in PS3.16, which allows a single Nesting Level (see in Section 6.1.2 “Nesting Level (NL)” in PS3.16 ). Constraints on the use of this Macro may be specified in PS3.16 Annex C, which may be invoked in IODs in PS3.3.
Table 10.2.1-1. Content Item with Modifiers Macro Attributes
Table 10-3. Image SOP Instance Reference Macro Attributes
Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
Identifies the Frame numbers within the Referenced SOP Instance to which the reference applies. The first Frame shall be denoted as Frame number 1. Required if the Referenced SOP Instance is a Multi-frame Image and the reference does not apply to all Frames, and Referenced Segment Number (0062,000B) is not present. |
|||
Identifies the Segment Number to which the reference applies. Required if the Referenced SOP Instance is a Segmentation or Surface Segmentation and the reference does not apply to all segments and Referenced Frame Number (0008,1160) is not present. |
Table 10-3b “Referenced Instances and Access Macro Attributes” contains identifiers and access details for a collection of Instances. It is intended to provide sufficient information to retrieve the referenced Instances.
Table 10-3b. Referenced Instances and Access Macro Attributes
Unique identifier for the Study. Required if Type of Instances (0040,E020) is DICOM and the Information Model of the referenced Instance contains the Study IE. |
|||
Unique identifier for the Series that is part of the Study identified in Study Instance UID (0020,000D), if present, and contains the referenced object Instance(s). Required if Type of Instances (0040,E020) is DICOM and the Information Model of the referenced Instance contains the Series IE. |
|||
Instance Identifier of the encapsulated HL7 Structured Document, encoded as a UID (OID or UUID), concatenated with a caret ("^") and Extension value (if Extension is present in Instance Identifier). |
|||
Identifies the Frame numbers within the Referenced SOP Instance to which the reference applies. The first Frame shall be denoted as Frame number 1. Required if the Referenced SOP Instance is a Multi-frame Image and the reference does not apply to all Frames, and Referenced Segment Number (0062,000B) is not present. |
|||
Identifies the Segment Number to which the reference applies. Required if the Referenced SOP Instance is a Segmentation and the reference does not apply to all segments and Referenced Frame Number (0008,1160) is not present. |
|||
Details for retrieving Instances via the DICOM Retrieve Service. Required if DICOM Media Retrieval Sequence (0040,E022), WADO Retrieval Sequence (0040,E023), WADO-RS Retrieval Sequence (0040,E025) and XDS Retrieval Sequence (0040,E024) are not present. May be present otherwise. This Sequence shall only identify sources known to have Instances referenced in Referenced SOP Sequence (0008,1199). |
|||
Title of a DICOM Application Entity where the referenced Instance(s) may be retrieved on the network. |
|||
Details for retrieving Instances from Media. Required if DICOM Retrieval Sequence (0040,E021), WADO Retrieval Sequence (0040,E023), and WADO-RS Retrieval Sequence (0040,E025) and XDS Retrieval Sequence (0040,E024) are not present. May be present otherwise. This Sequence shall only identify media known to have Instances referenced in Referenced SOP Sequence (0008,1199). |
|||
The user or implementation specific human readable identifier that identifies the Storage Media on which the referenced Instance(s) reside. |
|||
Uniquely identifies the Storage Media on which the referenced Instance(s) reside. |
|||
Details for retrieving Instances available via WADO-URI. NoteThis Sequence addresses use of the URI-based Web Access to DICOM Objects. Retrieval via the IHE XDS-I.b RAD-69 Transaction [IHE RAD TF-2] is addressed in the XDS Retrieval Sequence (0040,E024). Required if DICOM Retrieval Sequence (0040,E021), DICOM Media Retrieval Sequence (0040,E022), WADO-RS Retrieval Sequence (0040,E025) and XDS Retrieval Sequence (0040,E024) are not present. May be present otherwise. |
|||
URI/URL specifying the location of the referenced Instance(s). Includes fully specified scheme, authority, path, and query in accordance with [RFC3986]. |
|||
Details for retrieving Instances using the IHE XDS-I.b RAD-69 Transaction. NoteRetrieval via WADO-URI is addressed by the WADO Retrieval Sequence (0040,E023). Retrieval via WADO-RS is addressed by the WADO-RS Retrieval Sequence (0040,E025). Required if DICOM Retrieval Sequence (0040,E021), DICOM Media Retrieval Sequence (0040,E022), WADO-RS Retrieval Sequence (0040,E025) and WADO Retrieval Sequence (0040,E023) are not present. May be present otherwise. This Sequence shall only identify repositories known to have Instances referenced in Referenced SOP Sequence (0008,1199). |
|||
Uniquely identifies a Repository from which the referenced Instances can be retrieved. |
|||
Uniquely identifies a Community to which requests for the referenced Instances can be directed. |
|||
Details for retrieving Instances via WADO-RS. NoteRetrieval via WADO-URI is addressed in the WADO Retrieval Sequence (0040,E023). Retrieval via the IHE XDS-I.b RAD-69 Transaction [IHE RAD TF-2] is addressed in the XDS Retrieval Sequence (0040,E024). Required if DICOM Retrieval Sequence (0040,E021), DICOM Media Retrieval Sequence (0040,E022), WADO Retrieval Sequence (0040,E023) and XDS Retrieval Sequence (0040,E024) are not present. May be present otherwise. |
|||
Table 10-3c “Storage Macro Attributes” contains details for where and how to store Instances. It is intended to provide sufficient information to store Instances to the correct location.
This Macro mirrors Table 10-3b “Referenced Instances and Access Macro Attributes”.
Table 10-3c. Storage Macro Attributes
Uniquely identifies the referenced SOP Class. Required if the storage request only applies to a specific SOP Class. |
|||
Details for storing Instances via the DICOM Storage Service. Required if STOW-RS Storage Sequence (0040,4072) or XDS Storage Sequence (0040,4074) is not present. May be present otherwise. |
|||
Title of a DICOM Application Entity to which Instances will be stored. |
|||
Details for storing Instances via STOW-RS. Required if DICOM Storage Sequence (0040,4071) and XDS Storage Sequence (0040,4074) are not present. May be present otherwise. |
|||
URI/URL specifying the location of the STOW-RS storage service to which Instances will be stored. The Value shall be a fully specified URI with protocol, authority and path, in accordance with [RFC3986] and Section 10.5 “Store Transaction” in PS3.18. |
|||
Details for storing Instances via the IHE Provide and Register Document Set-b (ITI-41) transaction [IHE ITI TF-2b]. Required if STOW-RS Storage Sequence (0040,4072) and DICOM Storage Sequence (0040,4071) are not present. May be present otherwise. |
|||
Uniquely identifies a Repository from which the referenced Instances can be retrieved. |
|||
Uniquely identifies a Community to which requests for the referenced Instances can be directed. |
Table 10-4 specifies the Attributes of the Series and Instance Reference Macro, which lists Series, and SOP Instances within those Series.
Table 10-4. Series and Instance Reference Macro Attributes
Sequence of Items each of which includes the Attributes of one Series. |
|||
Unique identifier of the Series containing the referenced Instances. |
|||
Sequence of Items each providing a reference to an Instance that is part of the Series defined by Series Instance UID (0020,000E) in the enclosing Item. |
|||
>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
Table 10-5, Table 10-6, Table 10-7 and Table 10-7b specify the Attributes for identifying the general region of the Patient anatomy examined using coded terminology, as well as the principal structure(s) within that region that is the target of the current SOP Instance. The only differences between the Macros are the Type and Number of Items of the Anatomic Region Sequence (0008,2218). Table 10-8 describe the Attributes for the coding of the principal structure only.
The invocation of these Macros may specify Baseline or Defined CIDs for the Anatomic Region Sequence (0008,2218), the Anatomic Region Modifier Sequence (0008,2220), and/or the Primary Anatomic Structure Sequence (0008,2228).
The general region of the body (e.g., the anatomic region, organ, or body cavity being examined) is identified by the Anatomic Region Sequence (0008,2218). Characteristics of the anatomic region being examined, such as sub-region (e.g., medial, lateral, superior, inferior, lobe, quadrant) and laterality (e.g., right, left, both), may be refined by the Anatomic Region Modifier Sequence (0008,2220).
These Attributes allow the specification of the information encoded by the Body Part Examined (0018,0015) in the General Series Module in a more robust, consistent way.
The specific anatomic structures of interest within the image (e.g., a particular artery within the anatomic region) is identified by the Primary Anatomic Structure Sequence (0008,2228). Characteristics of the anatomic structure, such as its location (e.g., subcapsular, peripheral, central), configuration (e.g., distended, contracted), and laterality (e.g., right, left, both), and so on, may be refined by the Primary Anatomic Structure Modifier Sequence (0008,2230).
Laterality is often encoded in a separate Attribute, Image Laterality (0020,0062) or Frame Laterality (0020,9072), rather than in Anatomic Region Modifier Sequence (0008,2220) or Primary Anatomic Structure Modifier Sequence (0008,2230). The correspondence between the values is as follows:
The codes illustrated are from CID 244 “Laterality”.
Whether or not various anatomical structures may be paired or unpaired (have laterality) is illustrated in Table L-5 “Pairedness of Anatomic Concepts” in PS3.16.
Table 10-5. General Anatomy Mandatory Macro Attributes
Sequence that identifies the anatomic region of interest in this Instance (i.e., external anatomy, surface anatomy, or general region of the body). |
|||
Sequence of Items that modifies the anatomic region of interest of this Instance. |
|||
DCID 2 “Anatomic Modifier”, unless otherwise defined in the Macro invocation. |
|||
Include Table 10-8 “Primary Anatomic Structure Macro Attributes” |
Table 10-6. General Anatomy Required Macro Attributes
Sequence that identifies the anatomic region of interest in this Instance (i.e., external anatomy, surface anatomy, or general region of the body). |
|||
Sequence of Items that modifies the anatomic region of interest of this Instance |
|||
DCID 2 “Anatomic Modifier”, unless otherwise defined in the Macro invocation. |
|||
Include Table 10-8 “Primary Anatomic Structure Macro Attributes” |
Table 10-7. General Anatomy Optional Macro Attributes
Sequence that identifies the anatomic region of interest in this Instance (i.e., external anatomy, surface anatomy, or general region of the body). |
|||
Sequence of Items that modifies the anatomic region of interest of this Instance |
|||
DCID 2 “Anatomic Modifier”, unless otherwise defined in the Macro invocation. |
|||
Include Table 10-8 “Primary Anatomic Structure Macro Attributes” |
Table 10-7b. Multiple Site General Anatomy Optional Macro Attributes
Sequence that identifies the anatomic region of interest in this Instance (i.e., external anatomy, surface anatomy, or general region of the body). |
|||
Sequence of Items that modifies the anatomic region of interest in this Instance |
|||
DCID 2 “Anatomic Modifier”, unless otherwise defined in the Macro invocation. |
|||
Include Table 10-8 “Primary Anatomic Structure Macro Attributes” |
Table 10-8. Primary Anatomic Structure Macro Attributes
Table 10-9. Request Attributes Macro Attributes
Identifier that identifies the Requested Procedure in the Imaging Service Request. Required if procedure was scheduled. May be present otherwise. NoteThe condition is to allow the contents of this Macro to be present (e.g., to convey the reason for the procedure, such as whether a mammogram is for screening or diagnostic purposes) even when the procedure was not formally scheduled and a value for this identifier is unknown, rather than making up a dummy value. |
|||
A departmental Information System generated number that identifies the Imaging Service Request. |
|||
Identifier of the Assigning Authority that issued the Accession Number. |
|||
>Include Table 10-17 “HL7v2 Hierarchic Designator Macro Attributes” |
|||
The unique identifier for the Study provided for this Requested Procedure. |
|||
Uniquely identifies the Studies associated with this SOP Instance. One or more Items are permitted in this Sequence. See Section 10.6.1. |
|||
>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
Institution-generated administrative description or classification of Requested Procedure. |
|||
A Sequence that conveys the Procedure Type of the requested procedure. |
|||
Identifier that identifies the Scheduled Procedure Step. Required if procedure was scheduled. NoteThe condition is to allow the contents of this Macro to be present (e.g., to convey the reason for the procedure, such as whether a mammogram is for screening or diagnostic purposes) even when the procedure step was not formally scheduled and a value for this identifier is unknown, rather than making up a dummy value. |
|||
Institution-generated description or classification of the Scheduled Procedure Step to be performed. |
|||
Sequence describing the Scheduled Protocol following a specific Coding Scheme. One or more Items are permitted in this Sequence. |
|||
Sequence that specifies the context for the Scheduled Protocol Code Sequence (0040,0008) Item. One or more Items are permitted in this Sequence. |
|||
Sequence that specifies modifiers for a Protocol Context Content Item. One or more Items are permitted in this Sequence. See Section C.4.10.1. |
|||
>>>Include Table 10-2 “Content Item Macro Attributes” |
Since Referenced Study Sequence (0008,1110) is Type 2 or 3 in each usage, the Attribute may be zero length or omitted, respectively.
If Referenced Study Sequence (0008,1110) is present with an Item, the SOP Class UID of the Detached Study Management SOP Class (Retired) may be used in Referenced SOP Class UID (0008,1150).
Table 10-10 specifies the Attributes of the Basic Pixel Spacing Calibration Macro.
Table 10-10. Basic Pixel Spacing Calibration Macro Attributes
Physical distance in the Patient between the center of each pixel, specified by a numeric pair - adjacent row spacing (delimiter) adjacent column spacing in mm. See Section 10.7.1.1 and Section 10.7.1.3. Required if the image has been calibrated. May be present otherwise. |
|||
The type of correction for the effect of geometric magnification or calibration against an object of known size, if any. See Section 10.7.1.2. |
|||
A free text description of the type of correction or calibration performed. Note
Required if Pixel Spacing Calibration Type (0028,0A02) is present. |
Pixel Spacing (0028,0030) specifies the physical distance in the Patient between the center of each pixel.
If Pixel Spacing (0028,0030) is present and the image has not been calibrated to correct for the effect of geometric magnification, the Values of this Attribute shall be the same as in Imager Pixel Spacing (0018,1164) or Nominal Scanned Pixel Spacing (0018,2010), if either of those Attributes are present.
If Pixel Spacing (0028,0030) is present and the Values are different from those in Imager Pixel Spacing (0018,1164) or Nominal Scanned Pixel Spacing (0018,2010), then the image has been corrected for known or assumed geometric magnification or calibrated with respect to some object of known size at known depth within the Patient.
If Pixel Spacing Calibration Type (0028,0A02) and Imager Pixel Spacing (0018,1164) and Nominal Scanned Pixel Spacing (0018,2010) are absent, then it cannot be determined whether or not correction or calibration have been performed.
The Pixel Spacing Calibration Type (0028,0A02) specifies the type of correction for the effect of geometric magnification or calibration against an object of known size, if any.
Enumerated Values:
The Pixel Spacing (0028,0030) Values account for assumed or known geometric magnification effects and correspond to some unspecified depth within the Patient; the Pixel Spacing (0028,0030) Values may thus be used for measurements of objects located close to the central ray and at the same depth.
The Pixel Spacing (0028,0030) Values have been calibrated by the operator or image processing software by measurement of an object (fiducial) that is visible in the pixel data and is of known size and is located close to the central ray; the Pixel Spacing (0028,0030) Values may thus be used for measurements of objects located close to the central ray and located at the same depth within the Patient as the fiducial.
All pixel spacing related Attributes are encoded as the physical distance between the centers of each two-dimensional pixel, specified by two numeric Values.
The first Value is the row spacing in mm, that is the spacing between the centers of adjacent rows, or vertical spacing.
The second Value is the column spacing in mm, that is the spacing between the centers of adjacent columns, or horizontal spacing.
To illustrate, consider the example shown in Figure 10.7.1.3-1.
Pixel Spacing = Row Spacing \ Column Spacing = 0.30\0.25.
All pixel spacing related Attributes shall have positive non-zero Values, except when there is only a single row or column or pixel of data present, in which case the corresponding Value may be zero.
A single row or column or "pixel" may occur in MR Spectroscopy Instances. If the Value is non-zero, its purpose may be to convey the dimensions of a single row or column or pixel, such as in single voxel MR Spectroscopy; there is no other mechanism for conveying this.
Table 10-11 specifies the Attributes of the SOP Instance Reference Macro, which references a SOP Instance.
Table 10-12 specifies the Attributes of the Content Identification Macro, which identify and describe a SOP Instance potentially created by a human user interacting with an application.
Table 10-12. Content Identification Macro Attributes
Table 10.9.1-1 specifies the Attributes of the Enhanced Content Identification Macro, which identifies content using a label supporting lower case characters and specified character sets. If a Code String is required, see Section 10.9 “Content Identification Macro”.
Table 10.9.1-1. Enhanced Content Identification Macro Attributes
User-defined label for this SOP Instance. See Section 10.9.1.1.1. |
|||
User-defined description for the content of this SOP Instance. See Section 10.9.1.1.1. |
|||
User Content Label (3010,0033) shall represent a user-defined short free text providing the primary identification of this entity to other users. Content Description (0070,0081) allows a longer string containing additional descriptive identifying text.
This information is intended for display to human readers. Shall not be used for structured processing.
Table 10.9.2-1 specifies the Attributes of the Extended Content Identification Macro, which identifies content using a label supporting lower case characters and specified character sets. If a Code String is required, see Section 10.9 “Content Identification Macro”.
Table 10.9.2-1. Extended Content Identification Macro Attributes
User-defined label for the content of this SOP Instance. See Section 10.9.2.1.1. |
|||
User-defined description for the content of this SOP Instance. See Section 10.9.2.1.1. |
|||
User Content Long Label (3010,0034) shall represent a user-defined free text providing the primary identification of this entity to other users. Content Description (0070,0081) allows a longer string containing additional descriptive identifying text.
This information is intended for display to human readers. Shall not be used for structured processing.
Table 10.9.3-1. Content Creator Macro Attributes
Name of operator (such as a technologist or physician) creating the content of the SOP Instance. |
|||
>Include Table 10-1 “Person Identification Macro Attributes” |
Table 10-13 specifies the Attributes of the General Contributing Sources Macro, which describe the general characteristics of the contributing sources used to create a new SOP Instance.
Table 10-13. General Contributing Sources Macro Attributes
A Sequence that identifies the contributing SOP Instances. Required if this SOP Instance is created from other DICOM SOP Instances. |
|||
Unique identifier for the Study of the Contributing SOP Instances. |
|||
Sequence of Items each of which includes the Attributes of one Series. |
|||
Unique identifier of the Series containing the referenced Instances. |
|||
Sequence of Items each providing a reference to an Instance that is part of the Series defined by Series Instance UID (0020,000E) in the enclosing Item. |
|||
>>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
Manufacturer's model name of the equipment that produced the sources. Required if present and consistent in the contributing SOP Instances. |
|||
Manufacturer's serial number of the equipment that produced the sources. Required if present and consistent in the contributing SOP Instances. |
|||
Manufacturer's designation of software version of the equipment that produced the sources. See Section C.7.5.1.1.3. Required if present and consistent in the contributing SOP Instances. |
|||
The date the equipment that produced the sources was originally manufactured or re-manufactured (as opposed to refurbished). |
|||
The date the equipment that produced the sources was installed in its current location. The device may or may not have been used prior to installation in its current location. |
|||
The time the acquisition of data that resulted in sources started. The Value shall be the start date and time of the first contributing SOP Instance of the group specified by the Contributing SOP Instances Reference Sequence (0020,9529). Required if present and consistent in the contributing SOP Instances. |
|||
User defined name identifying the machine that produced the sources. Required if present and consistent in the contributing SOP Instances. |
|||
Name(s) of the operator(s) supporting the Series. Required if present and consistent in the contributing SOP Instances. |
|||
Identification of the operator(s) supporting the Series. One or more Items shall be included in this Sequence. If more than one Item, the number and order shall correspond to the Value of Operators' Name (0008,1070), if present. Required if present and consistent in the contributing SOP Instances. |
|||
>Include Table 10-1 “Person Identification Macro Attributes” |
|||
User-defined description of the conditions under which the Series was performed. Required if present and consistent in the contributing SOP Instances. |
|||
Sequence describing the Protocol performed for the Procedure Step creating the sources. One or more Items shall be included in this Sequence. Required if present and consistent in the contributing SOP Instances. |
|||
User defined name of the protocol used to acquire this image. Required if present and consistent in the contributing SOP Instances. |
The Attributes at the first level of the General Contributing Sources Macro contain information that is common to all the Referenced SOP Instances included in the Contributing SOP Instances Reference Sequence. This allows to not duplicate information when the contributing Instances are single-frame objects and/or when they are in different Series with the same protocol and manufacturer information.
Typically the General Contributing Sources Macro is invoked from inside another Sequence. Therefore, if the "common" Attributes of the Macro are different among the Referenced SOP Instances, like different acquisition protocols, software versions etc., the invoking Sequence will contain several Items.
Table 10-14 specifies the Attributes of the Contributing Image Sources Macro, which describe the image related characteristics of the contributing image sources used to create a new SOP Instance (e.g., a volume SOP Instance).
Table 10-14. Contributing Image Sources Macro Attributes
Number of bits stored for each pixel sample. Each sample shall have the same number of bits stored. See PS3.5 for further explanation. |
|||
Specifies whether the Source Images have undergone lossy compression (at a point in their lifetime). Enumerated Values: See Section C.7.6.1.1.5. Required if it is known whether or not Lossy Compression has been performed on the Images. |
|||
Describes the approximate lossy compression ratio(s) that have been applied to this image. |
|||
A label for the lossy compression method(s) that have been applied to the source images. |
Table 10-15 specifies the Attributes of the Patient Orientation Macro, which describe the Patient Orientation related to gravity and equipment.
Table 10-15. Patient Orientation Macro Attributes
Description of the orientation of the Patient with respect to gravity. See Section C.8.4.6.1.1 and Section C.8.11.5.1.2 for further explanation. |
|||
Required if needed to fully specify the orientation of the Patient with respect to gravity. |
|||
Description of the orientation of the Patient with respect to the gantry. See Section C.8.4.6.1.3 for further explanation. |
|||
Table 10-15a contains Attributes that describe the Patient Orientation related to gravity and the mandatory relationship to the equipment.
Table 10-15a. Patient Orientation and Equipment Relationship Macro Attributes
Sequence that describes the orientation of the Patient with respect to gravity. See Section C.8.4.6.1.1 and Section C.8.11.5.1.2 for further explanation. |
|||
Required if needed to fully specify the orientation of the Patient with respect to gravity. |
|||
Description of the orientation of the Patient with respect to the equipment. See Section C.36.6.1.8 for further explanation. |
|||
The Attributes of this Macro may be used to correlate the Patient-Based Coordinate System (see Section C.7.6.2) and the equipment.
Table 10-16. Performed Procedure Step Summary Macro Attributes
User or equipment generated identifier of that part of a Procedure that has been carried out within this step. |
|||
Institution-generated description or classification of the Procedure Step that was performed. |
|||
Sequence describing the Protocol performed for this Procedure Step. One or more Items are permitted in this Sequence. |
|||
Sequence that specifies the context for the Performed Protocol Code Sequence (0040,0260) Item. One or more Items are permitted in this Sequence. |
|||
Sequence that specifies modifiers for a Protocol Context Content Item. One or more Items are permitted in this Sequence. See Section C.4.10.1. |
|||
>>>Include Table 10-2 “Content Item Macro Attributes” |
|||
Table 10-17 specifies the Attributes of the HL7v2 Hierarchic Designator Macro, which identify an entity (system, organization, agency, or department) that has responsibility for managing or assigning a defined set of instance identifiers (such as placer or filler number, Patient identifiers, provider identifiers, etc.). This entity could be a particular health care application such as a registration system that assigns Patient identifiers, a governmental entity such as a licensing authority that assigns professional identifiers or drivers' license numbers, or a facility where such identifiers are assigned.
This definition is identical to HL7 v2.5, Section 2.A.33, with only minor changes for editorial style.
These Attributes are equivalent to the components of the HL7 v2 Hierarchic Designator (HD) and Entity Identifier (EI) data types (see HL7 v2 Chapter 2.A).
If both Local Namespace Entity ID (0040,0031) and Universal Entity ID (0040,0032) are present, they shall refer to the same entity.
Table 10-17. HL7v2 Hierarchic Designator Macro Attributes
Table 10-18 specifies the Attributes of the Issuer of Patient ID Macro, which identify the source of Patient ID (0010,0020).
These Attributes are equivalent to components of the HL7 v2 Extended Composite ID with Check Digit (CX) data type (see HL7 v2 Chapter 2.A.14), as used in the HL7 v2 PID-3 Patient Identifier List field.
Table 10-18. Issuer of Patient ID Macro Attributes
Identifier of the Assigning Authority (system, organization, agency, or department) that issued the Patient ID. |
|||
Attributes specifying or qualifying the identity of the issuer of the Patient ID, or scoping the Patient ID. |
|||
Universal or unique identifier for the Patient ID Assigning Authority. The authority identified by this Attribute shall be the same as that of Issuer of Patient ID (0010,0021), if present. |
|||
Standard defining the format of the Universal Entity ID (0040,0032). Required if Universal Entity ID (0040,0032) is present. See Section 10.14 for Defined Terms. |
|||
Type of Patient ID. Refer to HL7 v2 Table 0203 for Defined Terms. |
|||
The place or location identifier where the identifier was first assigned to the Patient. This component is not an inherent part of the identifier but rather part of the history of the identifier. |
|||
>>Include Table 10-17 “HL7v2 Hierarchic Designator Macro Attributes” |
|||
The geo-political body that assigned the Patient identifier. Typically a code for a country or a state/province. Only a single Item is permitted in this Sequence. |
|||
BCID 5001 “Country” for country codes. |
|||
The agency or department that assigned the Patient identifier. Only a single Item is permitted in this Sequence. |
|||
Table 10-19 specifies the Attributes of the Algorithm Identification Macro, which identifies and describes the algorithm used to create or derive a SOP Instance contents. An algorithm is described by the Algorithm Family, a specific Algorithm Name, and an Algorithm Version. A character string containing parameters that were used in the algorithm can be included.
Table 10-19. Algorithm Identification Macro Attributes
Table 10-20 specifies the Attributes of the Selector Attribute Macro, which identify either a particular Value of an Attribute, all Values of an Attribute, a specific Item in a Sequence, or all Items in a Sequence. The Attribute or Item may be nested within one or more Sequences, and/or a Private Attribute.
The invocation of the Selector Attribute Macro may define additional semantics. E.g., if the Selector Attribute Macro is used to select "all" Values of an Attribute and then test that set of Value against some condition, then an invocation might define whether it is required that at least one Value in the set meet the condition or whether all Values in the set must meet the condition.
Table 10-20a extends the Selector Attribute Macro with additional Attribute descriptors.
Table 10-20. Selector Attribute Macro Attributes
Non-negative integer identifying which Value of a multi-valued Attribute identified by Selector Attribute (0072,0026) is to be referenced. The Value 1 identifies the first Value. The Value 0 identifies all Values. When the Value Multiplicity of the Selector Attribute (0072,0026) is 1 then the Value of this Attribute shall be 1. Required if the selected content is a single Attribute of any VR other than SQ. |
|||
Contains the Data Element Tags of the path to the Sequence that contains the Attribute that is identified by Selector Attribute (0072,0026) or to the Item(s) to be selected in Selector Sequence Pointer Items (0074,1057). This Attribute shall have the same number of Values as the level of nesting of Selector Attribute (0072,0026) or the selected Item(s). Required if Selector Attribute (0072,0026) is nested in one or more Sequences or is absent. See Section 10.17.1.1. |
|||
Identification of the creator of a group of Private Data Elements used to encode Attributes in the Selector Sequence Pointer (0072,0052). This Attribute shall have the same number of Values as Selector Sequence Pointer (0072,0052). For Values of the Selector Sequence Pointer (0072,0052) that are not the Data Element Tag of a Private Attribute, the corresponding Value in Selector Sequence Pointer Private Creator (0072,0054) shall be empty. Required if Selector Sequence Pointer (0072,0052) is present and one or more of the Values of Selector Sequence Pointer (0072,0052) is the Data Element Tag of a Private Attribute. See Section 10.17.1.2. |
|||
Identification of the Item indices in the Selector Sequence Pointer (0072,0052). This Attribute shall have the same number of Values as the Selector Sequence Pointer (0072,0052). The Value 1 identifies the first Item of the corresponding Sequence. The Value 0 identifies all Items of the corresponding Sequence. Required if Selector Sequence Pointer (0072,0052) is present. See Section 10.17.1.1. |
|||
Identification of the creator of a group of Private Data Elements. Required if the Selector Attribute (0072,0026) Value is the Data Element Tag of a Private Attribute. See Section 10.17.1.2. |
Table 10-20a. Extended Selector Attribute Macro Attributes
Name of the Selector Attribute (0072,0026). For Standard Data Elements, this shall be the Value in the Name column of Table 6-1 in PS3.6. |
|||
Keyword of the Selector Attribute (0072,0026). For Standard Data Elements, this shall be the Value in the Keyword column of Table 6-1 in PS3.6. |
|||
Value Representation of the Selector Attribute (0072,0026). For Standard Data Elements, this shall be the Value in the VR column of Table 6-1 in PS3.6. |
|||
Examples of use are shown in Table 10-21.
The examples include the selection of a top level Attribute, a nested Attribute, one Item in a top level Sequence, all Items in a nested Sequence or a specific Item in all Items of a parent Sequence.
Table 10-21. Selector Attribute Macro Example
The Selector Sequence Pointer Private Creator (0072,0054) and the Selector Attribute Private Creator (0072,0056) each have a Value that corresponds to the Private Creator Data Element numbers (gggg,00pp), where gggg is odd and pp ranges from 10 to FF. These identify a block of Private Data Elements within the block (gggg,ppxx). When Selector Attribute (0072,0026) or Selector Sequence Pointer (0072,0052) points to a Private Data Element (gggg,ppxx), it shall have the Value (gggg,00xx).
Table 10-22 specifies the Attributes of the Externally-Sourced Data Set Identification Macro, which identify an Externally-Sourced Data Set.
Table 10-22. Externally-Sourced Data Set Identification Macro Attributes
Table 10-23 specifies the Attributes of the Section 10.19 Exposure Index Macro, which describe the Exposure Index for single projection X-Ray images, as described by IEC 62494-1 and the report of AAPM Task Group 116.
Table 10-23. Exposure Index Macro Attributes
Table 10-24 specifies the Attributes of the Mandatory View and Slice Progression Direction Macro, which describe the view, and in the case of cardiac views, the direction of the slices relative to the cardiac anatomy.
Table 10-24. Mandatory View and Slice Progression Direction Macro Attributes
Sequence that describes the projection of the anatomic region of interest. |
|||
BCID 26 “Nuclear Medicine Projection” unless otherwise specified in invocation. |
|||
BCID 23 “Cranio-Caudad Angulation” unless otherwise specified in invocation. |
|||
Describes the anatomical direction in which a set of slices is progressing (see Section 10.20.1.1). Meaningful only for cardiac images. Enumerated Values are defined in Section 10.20.1.1. Required if View Code Sequence (0054,0220) equals (103340004, SCT, "Short Axis") or (131185001, SCT, "Vertical Long Axis") or (131186000, SCT, "Horizontal Long Axis"). May be present otherwise. |
The image or Frame order to which the Slice Progression Direction (0054,0500) applies depends on the IOD:
In the case of Enhanced Multi-frame IODs, in which a Stack ID (0020,9056) may be defined, Stack ID (0020,9056) shall be used, and the slices are considered in order by In Stack Position Number (0020,9057)
In the case of Multi-frame Image IODs that are not Enhanced, the slices are considered in encoded Frame order
In the case of Single-frame Image IODs, the order is defined by increasing Values of Instance Number
The Enumerated Values depend on the view:
If View Code Sequence (0054,0220) indicates a short axis view, such as when it equals (103340004, SCT, "Short Axis"):
If View Code Sequence (0054,0220) indicates a vertical long axis view, such as when it equals (131185001, SCT, "Vertical Long Axis"):
If View Code Sequence (0054,0220) indicates a horizontal long axis view, such as when it equals (131186000, SCT, "Horizontal Long Axis"):
The conditions on the choice of Enumerated Values are relatively general, rather than specific to a single coded view, in order to accommodate the echocardiography views defined in CID 12226 “Echocardiography Image View” in PS3.16 , in addition to the views for CT, MR, NM and PET defined in CID 26 “Nuclear Medicine Projection” in PS3.16 .
Table 10-25 specifies the Attributes of the Optional View and Slice Progression Direction Macro, which describe the view, and in the case of cardiac views, the direction of the slices relative to the cardiac anatomy.
Table 10-25. Optional View and Slice Progression Direction Macro Attributes
Sequence that describes the projection of the anatomic region of interest. |
|||
BCID 26 “Nuclear Medicine Projection” unless otherwise specified in invocation. |
|||
BCID 23 “Cranio-Caudad Angulation” unless otherwise specified in invocation. |
|||
Describes the anatomical direction in which a set of slices is progressing (see Section 10.20.1.1). Meaningful only for cardiac images. Enumerated Values are defined in Section 10.20.1.1. |
Table 10-26 specifies the Attributes of the Numeric Value Macro, which is used to relate and convey a numeric value to a coded concept.
Table 10-26. Numeric Value Macro Attributes
Retired. See PS3.3-2024b.
Table 10-28 specifies the Attributes of the Device Motion Control Macro, which describe requirements on performing the movement of a device from an actual to a desired position.
Table 10-28. Device Motion Control Macro Attributes
Device Motion Control Definitions for each degree of freedom. |
|||
The parameter for which the Device Motion Control shall be applied. |
|||
Permitted Motion Execution Mode for movement. Required if Device Motion Observation Mode (300A,0452) is absent. May be present otherwise. See Section 10.24.1.1. |
|||
Required Motion Observation Mode for movement. Required if Device Motion Execution Mode (300A,0451) is absent. May be present otherwise. See Section 10.24.1.2. |
Device Motion Execution Mode (300A,0451) identifies how the operator invokes and controls the motion.
Enumerated Values:
The device must be moved while the operator is activating one or more switches on the machine during the whole period of movement to prevent any uncontrolled movement.
The device can be moved automatically to the desired position, triggered by a one-time command of the operator, without the need to constantly activate any switch.
The device movement can be initiated and performed automatically by the device to the desired position.
Table 10.25-1 specifies the Attributes of the Attribute Value Constraint Macro, which allows an Attribute to be identified and to have constraints placed on acceptable Values for that Attribute. An Attribute being constrained is referred to in the Macro as a Selector Attribute.
This Macro does not handle mutual constraints between multiple Attributes. For example constraining the ratio between two Attributes to a specific Value is not possible unless there is a third Attribute that encodes that ratio so the third Attribute could then be constrained.
The SOP Instance containing this Macro defines the purpose of the constraints, which may include constraining Attribute Values in other SOP Instances.
Table 10.25-1. Attribute Value Constraint Macro Attributes
Include Table 10-20a “Extended Selector Attribute Macro Attributes” |
|||
Describes how the Value(s) specified in the Constraint Value Sequence (0082,0034) shall be used to determine the acceptability of a given Value for the Attribute identified by Selector Attribute (0072,0026) See Section 10.25.1. |
|||
Level of significance of a Selector Attribute Value exceeding this constraint. See Section 10.25.2. |
|||
Conditionality of the constraint violation significance. If the condition is not met, the violation has no significance. The condition may be expressed as a mathematical expression, a human readable text or other form. Required if Constraint Violation Significance (0082,0036) is only significant under certain conditions. |
|||
Value(s) used to constrain the contents of the Attribute referenced by the Selector Attribute (0072,0026). Required if Constraint Type (0082,0032) is not UNCONSTRAINED. If the Constraint Type (0082,0032) is GREATER_OR_EQUAL, LESS_OR_EQUAL, GREATER_THAN, LESS_THAN, EQUAL or MEMBER_OF_CID only a single Item shall be included in this Sequence. If the Constraint Type (0082,0032) is RANGE_INCL or RANGE_EXCL, exactly two Items shall be included in this Sequence, the first of which is less than or equal to the second. If the Constraint Type (0082,0032) is MEMBER_OF or NOT_MEMBER_OF, one or more Items shall be included in this Sequence. |
|||
Any sub-Sequences in the Constraint Value Sequence (0082,0034) shall only contain one Item. Any Attribute in the Sequence Item(s) shall contain a single Value. If Constraint Type (0082,0032) is MEMBER_OF_CID, this shall be a Selector UI Value (0072,007F), despite the Selector Attribute VR (0072,0050) being SQ. |
|||
Contains a default Value for the contents of the Selector Attribute (0072,0026). |
|||
Units of measurement for the Values in the Item(s) in the Constraint Value Sequence (0082,0034) and the Recommended Default Value Sequence (0082,0035). |
|||
Brief guidance that a human operator may consider when selecting an appropriate value for the Selector Attribute (0072,0026) within the constraints defined. |
The use of the specified value(s) in the Constraint Value Sequence (0082,0034) to constrain the Value of the Attribute referenced by the Selector Attribute (0072,0026) shall depend on the Value of Constraint Type (0082,0032) as follows:
the value is constrained to lie between the specified values, or be equal to one of the specified values
the value is constrained to lie outside (i.e., not between) the specified values
the value is constrained to be greater than or equal to the specified value
the value is constrained to be less than or equal to the specified value
the value is constrained to be greater than the specified value
the value is constrained to be less than the specified value
the value is constrained to be equal to one of the specified values
the value is constrained to be not equal to any of the specified values
the value is constrained to be equal to a member of the specified CID
the Value of the Selector Attribute (0072,0026) is not constrained
For MEMBER_OF_CID, Constraint Value Sequence (0082,0034) shall contain a single Selector UI Value (0072,007F), containing a Context Group UID (see Table A-3 Context Group UID Values in PS3.6 ).
RANGE_INCL, RANGE_EXCL, GREATER_OR_EQUAL, LESS_OR_EQUAL, GREATER_THAN or LESS_THAN shall only be specified if the Selector Attribute (0072,0026) is AS, DA, DS, DT, FD, FL, IS, SL, SS, TM, UL or US.
See Section C.2.2.2 in PS3.4 for further guidance on value comparison.
MEMBER_OF with a single Item in the Constraint Value Sequence (0082,0034) is valid and is equivalent to EQUAL.
If the Attribute referenced by the Selector Attribute (0072,0026) has a Value Multiplicity of greater than 1 and the Value of Selector Value Number (0072,0028) is 0, all Values in the selected Attribute shall be compared to the single specified Value. The constraint is violated if any of the multiple Values do not satisfy the comparison.
The violation of some constraints may be more significant than others. Constraint Violation Significance (0082,0036) differentiates three levels of significance.
Specific behaviors associated with each level may be defined by the SOP Class or may be left to implementations. For example, violation of a constraint with a significance of FAILURE might require operator intervention, special auditing or rejection of the target Instance being evaluated; violation of a constraint with a significance of WARNING might require the operator be notified or a warning message be logged; violation of a constraint with a significance of INFORMATIVE might require an informational message be logged, or nothing at all if the constraint represents a preference not a significant concern.
Table 10.26-1 specifies the Attributes of the Attribute Value Macro, which includes an Attribute to store a Value of a specified VR.
Table 10.26-1. Attribute Value Macro Attributes
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is AE. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is AS. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is AT. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is CS. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is DA. See Note 2. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is DS. See Note 1 and Note 2. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is DT. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is FD. See Note 2. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is FL. See Note 2. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is IS. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is LO. |
|||
The Value of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is LT. |
|||
The Value of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is OB. |
|||
The Value of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is OD. |
|||
The Value of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is OF. |
|||
The Value of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is OL. |
|||
The Value of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is OV. |
|||
The Value of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is OW. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is PN. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is SH. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is SL. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is SS. |
|||
The Value of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is ST. |
|||
The Value of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is SV. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is TM. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is UC. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is UI. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is UL. |
|||
The Value of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is UN. |
|||
The Value of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is UR. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is US. |
|||
The Value of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is UT. |
|||
The Value of the Attribute identified by Selector Attribute (0072,0026). Required if Selector Attribute VR (0072,0050) is present and the Value is UV. |
|||
The Value(s) of the Attribute identified by Selector Attribute (0072,0026). One or more Items shall be included in this Sequence. See Section C.23.4.2.1.2. Required if Selector Attribute VR (0072,0050) is present and the Value is SQ and the Attribute referenced by the Selector Attribute (0072,0026) is a Code Sequence. |
|||
Table 10.27-1 specifies the Attributes of the Reference Location Macro, which allows a reference location in the context of a Patient or scan to be identified and described. E.g., the Macro may describe an anatomically defined location along the axis of a CT scan to prescribe the extent of a scan or reconstruction. The location might be internal to the Patient (and appear on a localizer image) or might be an external landmark (on which a laser is aligned).
Table 10.27-1. Reference Location Macro Attributes
Further elaboration of the Reference Location. The Value may include a description of the relative anatomical location, the appearance of the feature or landmark, or how it can be identified. |
|||
The anatomical feature or point of reference on which the reference location is based. |
|||
Characterizes the geometry of the reference location (e.g., a plane or point). |
|||
Positive offset (in mm) from the Reference Basis to the actual Reference Location. See Section 10.27.1. |
|||
Direction of the offset (in terms of patient position) from the Reference Basis to the Reference Location. |
Table 10.28-1 specifies the Attributes of the Protocol Element Identification Macro, which identifies and describes an element in a protocol such as an acquisition protocol, a reconstruction protocol or a storage protocol.
Table 10.28-1. Protocol Element Identification Macro Attributes
Identifies the protocol element and the order in which the elements are performed in the Protocol. |
|||
Description of the purpose this element serves in the protocol. Note
|
|||
Summary description of characteristics of this element. Note
|
Table 10.29-1 specifies the Attributes of the UDI Macro, which records details associated with a Unique Device Identifier (UDI).
Table 10.29-1. UDI Macro Attributes
The entire Human Readable Form of the UDI as defined by the Issuing Agency. See Section 10.29.1. |
|||
Further description in free form text describing the device. This can be used to distinguish between Items when multiple UDIs are recorded in a Sequence. |
The UDI is a combination of the Device Identifier and the Production Identifier.
The format of the string is defined by a corresponding Issuing Agency, such as:
GS1 - http://www.gs1.org
HIBCC - http://www.hibcc.org
ICCBBA - http://www.iccbba.org
Details for encoding a valid device identifier are managed by the Issuing Agency. For full documentation, refer to issuer materials.
The United States FDA requires the Issuing Agency to use only characters and numbers from the invariant character set of ISO/IEC 646 (ISO 7-bit coded character set also known as ISO IR 6). DICOM puts no constraints on the length of the string or the character sets beyond the UT Value Representation. Implementations should be prepared to handle very large strings and unusual characters.
Table 10.30-1 specifies the Attributes of the Assertion Macro, which is used to record Assertions made by a person or device about the content of a SOP Instance. The nature of the Assertion is defined by the Assertion Code.
The scope of the Assertion (e.g., whether it applies to the whole Instance, to a specific Item in a Sequence, etc.) is described at the point where the Macro is included. It is also expected that when this Macro is included, the Baseline CID for the Assertion Code Sequence (0044,0101) will be constrained.
Table 10.30-1. Assertion Macro Attributes
>Include Table C.17-3b “Identified Person or Device Macro Attributes” |
Organizational Role BCID 7452 “Organizational Role”. |
||
Date and time at which the Assertion expires. If this Attribute is absent or empty, it means the Assertion does not have a pre-determined date and time at which it expires. |
|||
Reference to document(s) that describe the Assertion semantics, or provide the basis for making the Assertion. |
|||
Unique identifier for the referenced document as used in DICOM Instance references (see Section C.12.1.1.6). |
|||
Instance Identifier of the referenced document, encoded as a UID (OID or UUID), concatenated with a caret ("^") and Extension value (if Extension is present in Instance Identifier). |
|||
Retrieval access path to the referenced document. Includes fully specified scheme, authority, path, and query in accordance with [RFC3986]. |
|||
Other Assertions which may be of interest to systems examining this Assertion. |
|||
Table 10.31-1 specifies the Attributes of the Entity Labeling Macro, which provides identification of an entity to a user.
This information is intended for display to human readers. Shall not be used for structured processing.
Table 10.31-1. Entity Labeling Macro Attributes
User-defined label for this entity. See Section 10.31.1.1. |
|||
User-defined name for this entity. See Section 10.31.1.2. |
|||
User-defined description for this entity. See Section 10.31.1.2. |
Table 10.32-1 specifies the Attributes of the Entity Long Labeling Macro, which provides identification of an entity to a user.
This information is intended for display to human readers. Shall not be used for structured processing.
Table 10.32-1. Entity Long Labeling Macro Attributes
User-defined label for this entity. See Section 10.32.2.1. |
|||
User-defined description for this entity. See Section 10.31.1.2. |
Table 10.33-1 specifies the Attributes of the Conceptual Volume Macro. A Conceptual Volume is an abstract entity used to identify an anatomic region (such as a planning target volume or a combination of multiple anatomic volumes) or non-anatomic volumes such as a bolus or a marker. A Conceptual Volume can be established without necessarily defining its spatial extent (for example a Conceptual Volume for a tumor can be established prior to segmenting it). The spatial extent of a Conceptual Volume may change over time (for example as treatment proceeds the tumor volume corresponding to the Conceptual Volume will change).
The spatial extent of a Conceptual Volume may be defined by any general-purpose entity that represents geometric information (such as Segmentation, Surface Segmentation, RT Structure Set SOP Instance and alike) or a combination thereof, although the Conceptual Volume does exist independently of a specific definition of its spatial extent.
A Conceptual Volume may also be defined as a combination of other Conceptual Volumes.
Examples for Conceptual Volumes:
A Conceptual Volume (with a Conceptual Volume UID (3010,0006) can be used to represent the treatment target in an RT Physician Intent SOP Instance based upon a diagnostic image set, although the actual delineation of a specific target volume has not yet taken place. Later, the target volume is contoured. The RT Segment Annotation SOP Instance references the volume contours and associates it with the Conceptual Volume via the Conceptual Volume UID (3010,0006).
In an adaptive workflow, the anatomic volume may change over time. The Conceptual Volume on the other hand does not change. Multiple RT Segment Annotation SOP Instances, each referencing different Segmentation Instances, can be associated with the same Conceptual Volume via the Conceptual Volume UID (3010,0006), making it possible to track the volume over time.
A Conceptual Volume may represent targets and/or anatomic regions for which manually calculated doses are tracked (for example, in emergency treatments). In this case, Conceptual Volumes may be instantiated first in an RT Physician Intent SOP Instance and subsequently used in RT Radiation SOP Instances, or may be first instantiated in the Radiation SOP Instances. After treatment, these Conceptual Volumes will be used in RT Radiation Records to track the delivered dose. Such Conceptual Volumes may never reference a segmentation, but serve as a key for referencing the Conceptual Volume across these different SOP Instances.
Table 10.33-1. Conceptual Volume Macro Attributes
Reference to the SOP Instance that contains the original definition of this Conceptual Volume identified by Conceptual Volume UID (3010,0006). Required when Conceptual Volume UID (3010,0006) was not issued in the current SOP Instance, but read from another SOP Instance. |
|||
>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
References one or more existing Conceptual Volumes that represent the same concept as the current Conceptual Volume. This Sequence might be used when Conceptual Volume references of existing SOP Instances are retrospectively identified as representing the same entity. One or more Items are permitted in this Sequence. See Section 10.33.1.1. |
|||
Reference to a SOP Instance that contains the Referenced Conceptual Volume UID (3010,000B) of the Equivalent Conceptual Volume. |
|||
>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
Description of a Conceptual Volume that was used to derive this Conceptual Volume. |
|||
A user-readable text description of how this Conceptual Volume was derived. |
|||
The set of Conceptual Volumes that were used to derive this Conceptual Volume. |
|||
UID identifying the Conceptual Volume that was used to derive this Conceptual Volume. |
|||
Index of the constituent in the Source Conceptual Volume Sequence. |
|||
>>Conceptual Volume Constituent Segmentation Reference Sequence |
Contains the reference to the constituents of the RT Segment Annotation Instance from which Conceptual Volume is derived. |
||
Reference to the SOP Instance that contains the Direct Segment Reference Sequence (3010,0023). Only a single Item shall be included in this Sequence. See Section 10.34.1.3. |
|||
>>>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
The Segment Reference Index (3010,0022) in the Segment Reference Sequence (3010,0021) corresponding to the segment representing this Conceptual Volume. Shall reference only segment Items that contain the Direct Segment Reference Sequence (3010,0023). |
|||
>>Include Table 10-19 “Algorithm Identification Macro Attributes” |
Conceptual Volumes can be declared to be equivalent to other Conceptual Volumes. In such cases, the Equivalent Conceptual Volumes Sequence (3010,000A) is used in derived SOP Instances which are aware of other SOP Instances defining a semantically equivalent volume, but using different Conceptual Volume UIDs (3010,0006).
The Derivation Conceptual Volume Sequence (3010,0014) may be used to describe how a Conceptual Volume is derived from one or more other Conceptual Volumes in cases where it may not be possible to describe the method of the derivation completely. Since the Conceptual Volume cannot be mathematically constructed from a derivation description, it will be defined explicitly by a segmentation.
The specification of derivation is different from combining Conceptual Volumes as defined in Section 10.34 “Conceptual Volume Segmentation Reference and Combination Macro”.
Table 10.34-1 specifies the Attributes of the Conceptual Volume Segmentation Reference and Combination Macro, which allows the combination of Conceptual Volumes as constituents of a combined volume. A representative example is to have the Left Lung and the Right Lung segmented, and then to declare the Lungs as a combined Conceptual Volume, for which prescription constraints can be defined.
The Macro also allows reference to RT Segment Annotation SOP Instances, which contain a segmented representation of the Conceptual Volume. At the invocation of this Macro it is declared, whether this segmented representation is required or not.
Figure 10.34-1 describes an RT Physician Intent Instance where Conceptual Volumes "Lung, left" and "Lung, right" are referenced, but not defined. In this example, the RT Segmentation Annotation Instances then define the volumetric information of the Conceptual Volumes by referencing a specific segment of a Segmentation Instance and a specific ROI in an RT Structure Set Instance.
Figure 10.34-1 describes an RT Physician Intent Instance defining Conceptual Volumes "Lung, left" and "Lung, right" and Conceptual Volume "Lung" as a combination of the first two without a direct reference to a volume definition.
Table 10.34-1. Conceptual Volume Segmentation Reference And Combination Macro Attributes
Indication that this Conceptual Volume is a combination of other Conceptual Volumes. |
|||
References to Conceptual Volumes which are constituents of this Conceptual Volume. See Section 10.34.1.1. Required if Conceptual Volume Combination Flag (3010,000E) equals YES. One or more Items shall be included in this Sequence. The combined Conceptual Volume UID shall not be included in the Sequence. |
|||
An index referenced in the Conceptual Volume Combination Expression (3010,000C) identifying the Conceptual Volume Constituent. |
|||
UID identifying the Conceptual Volume that is a constituent of the combined Conceptual Volume. |
|||
Reference to the SOP Instance that contains the original definition of the Conceptual Volume constituent identified by Constituent Conceptual Volume UID (3010,0013) in this Sequence. If this Conceptual Volume originated in the current SOP Instance, then the referenced SOP Instance UID is the current SOP Instance UID. |
|||
>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
>Conceptual Volume Constituent Segmentation Reference Sequence |
Contains a segmented representation of the Conceptual Volume constituent. Required if the Conceptual Volume Segmentation Defined Flag (3010,0010) equals YES and the Conceptual Volume is not a Combination of other Conceptual Volumes. Only a single Item shall be included in this Sequence. See Section 10.34.1.2. |
||
Reference to the SOP Instance that contains the Direct Segment Reference Sequence (3010,0023). Only a single Item shall be included in this Sequence. See Section 10.34.1.3. |
|||
>>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
The Segment Reference Index (3010,0022) in the Segment Reference Sequence (3010,0021) corresponding to the segment representing this Conceptual Volume. Shall reference only segment Items that contain the Direct Segment Reference Sequence (3010,0023). |
|||
Symbolic expression specifying the combination of Conceptual Volumes as a text string consisting of Conceptual Volume Constituent Index (3010,000D) Values, combination operators and parentheses. Required if Conceptual Volume Combination Flag (3010,000E) equals YES. See Section 10.34.1.1. |
|||
Human-readable description of the combination of Conceptual Volumes. This information is intended for display and shall not be used for structured processing. Required if Conceptual Volume Combination Flag (3010,000E) equals YES. |
|||
Indication that there are defined segmentations for this Conceptual Volume. |
|||
Contains a segmented representation of the Conceptual Volume. Required when Conceptual Volume Segmentation Defined Flag (3010,0010) equals YES and Conceptual Volume Combination Flag (3010,000E) equals NO. Only a single Item shall be included in this Sequence. See Section 10.34.1.4. |
|||
Reference to the SOP Instance that contains the Segment Reference Sequence (3010,0021) in which the segment is defined. Only a single Item shall be included in this Sequence. See Section 10.34.1.3. |
|||
>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
The Segment Reference Index (3010,0022) in the Segment Reference Sequence (3010,0021) corresponding to the segment representing this Conceptual Volume. In the segment Item referenced, the Direct Segment Reference Sequence (3010,0023) shall be present. |
For Conceptual Volumes specified as a combination of other Conceptual Volumes, the combination logic is specified by the text string Value of the Conceptual Volume Combination Expression (3010,000C).
A nested list notation is used to apply geometric operators to a set of Conceptual Volumes.
The first element of the list shall be one of the following geometric operators:
The result of a NEGATION operation is well-defined only if used as an operand to an INTERSECTION. NEGATION without context to an INTERSECTION results in an infinite Volume.
Subsequent elements shall specify arguments of the geometric operator. An argument is either a Conceptual Volume Constituent Index (3010,000D) Value (i.e., positive integer) or a parenthesized list of operations.
The grammar for the Conceptual Volume Combination Expression (<sexpr>) is shown below in BNF (Backus Naur Form) :
<sexpr> :: <cv> | <list> <cv> :: 1 | 2 | 3 | … <list> :: ( <op1><sp><sexpr> ) | ( <op2><sp><sexpr><sp><sexpr> ) | ( <op3><sp><args> ) <args> :: <sexpr><sp><sexpr> | <args><sp><sexpr> <op1> :: NEGATION <op2> :: SUBTRACTION | XOR <op3> :: UNION | INTERSECTION <sp> :: 0x20
Union of paired organs 1 and 2 (disjoint)
Conceptual Volume Combination Expression (3010,000C):
Items in Conceptual Volume Constituent Sequence (3010,0008):
Union of paired organs 1 and 2 (non-disjoint)
Conceptual Volume Combination Expression (3010,000C):
Items in Conceptual Volume Constituent Sequence (3010,0008) :
Union of two organs 1 and 2 with excluded volume 3 using NEGATION
Conceptual Volume Combination Expression (3010,000C):
(INTERSECTION (UNION 1 2) (NEGATION 3) )
Items in Conceptual Volume Constituent Sequence (3010,0008):
Union of paired organs 1 and 2, with exclusion of multiple volumes 3, 4 and 5
Conceptual Volume Combination Expression (3010,000C):
(INTERSECTION (UNION 1 2) (NEGATION (UNION 3 4 5) ))
Items in Conceptual Volume Constituent Sequence (3010,0008):
Intersection of overlapping volumes 1 and 2
Conceptual Volume Combination Expression (3010,000C):
Items in Conceptual Volume Constituent Sequence (3010,0008):
Intersection of disjoint volumes 1 and 2
Conceptual Volume Combination Expression (3010,000C):
Items in Conceptual Volume Constituent Sequence (3010,0008):
The Conceptual Volume Constituent Segmentation Reference Sequence (3010,0012) contains a reference to a segmentation which represents the volume of this constituent geometrically. The referenced segmentations of the constituents of a combined Conceptual Volume may be in one or more Frames of References.
The Conceptual Volume constituents shall not include the combined Conceptual Volume being defined. Applications that wish to combine existing segmentations within the same Conceptual Volume must create a new Segmentation Instance.
A SOP Instance may only be referenced in this Sequence if it belongs to a SOP Class that includes the Section C.36.9 Segment Reference Module.
Table 10.35-1 specifies the Attributes of the Device Model Macro, which contains general Attributes needed to specify a device model other than the device creating the SOP Instance.
Table 10.36-1 specifies the Attributes of the Device Identification Macro, which identifies a (physical or virtual) device.
Table 10.36-1. Device Identification Macro Attributes
Manufacturer's designation of software version of the equipment. |
|||
The date the device was originally manufactured or re-manufactured (as opposed to refurbished). |
|||
The date the device was installed in its current location. The device may or may not have been used prior to installation in its current location. |
|||
>Include Table 10.29-1 “UDI Macro Attributes” |
|||
An identifier intended to be read by a device such as a bar code reader. |
|||
Defines the type of Device Alternate Identifier. Required if Device Alternate Identifier (3010,001B) has a Value. |
|||
Description of the format in which the Device Alternate Identifier (3010,001B) is issued. Required if Device Alternate Identifier (3010,001B) has a Value. See Section 10.36.1.1. |
Typically, the Device Identifier is a code which can be electronically read by the machine utilizing that device, e.g. to verify the presence of that device.
The Device Alternate Identifier Format (3010,001D) specifies the format of the Value of the Device Alternate Identifier (3010,001B).
If the Value of Device Alternate Identifier Type (3010,001C) is RFID, a big variety of RFID formats exists (some examples are DOD-96, DOD-64 UID, GID-96, sgtin-96). Supported format values shall be defined in the Conformance Statement.
For Device Alternate Identifier Type (3010,001C) = BARCODE, see Section C.22.1.1.
Table 10.37-1 specifies the Attributes of the Related Information Entities Macro, which defines references to entities and their purpose of reference. References can be made at the Study level, Series level, Instance level or Frame Level.
The Attributes Pertinent SOP Classes in Study (3010,0052) and Pertinent SOP Classes in Series (3010,0053) allow the specification of the relevant SOP Classes for the given purpose. These Attributes support filtering for certain SOP Classes, specification of corresponding query keys, and allowing the receiving application to assess its capabilities to handle the specified objects.
All referenced Studies, Series and Instances share the same single Purpose of Reference.
Table 10.37-1. Related Information Entities Macro Attributes
The SOP Classes in the Study which are relevant for the invocation context. If not present, all SOP Instances included in the referenced Study are considered relevant. |
|||
The SOP Classes in the Series which are relevant for the invocation context. If not present, all SOP Instances included in the referenced Series are considered relevant. |
|||
Image SOP Instances which are relevant in the invocation context. |
|||
>>>Include Table 10-3 “Image SOP Instance Reference Macro Attributes” |
|||
Non-Image SOP Instances which are relevant in the invocation context. |
|||
>>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
Table 10.38-1 specifies the Attributes of the Outline Definition Macro, which describes a 2D outline in a given coordinate system.
Table 10.38-1. Outline Definition Macro Attributes
See Section 10.38.1.1. |
|||
X-coordinate in mm of the left edge of the rectangular outline (parallel to the y-axis of the coordinate system). Required if Outline Shape Type (0018,1630) is RECTANGULAR. See Section 10.38.1.2. |
|||
X-coordinate in mm of the right edge of the rectangular outline (parallel to the y-axis of the coordinate system). Required if Outline Shape Type (0018,1630) is RECTANGULAR. See Section 10.38.1.2. |
|||
Y-coordinate in mm of the upper edge of the rectangular outline (parallel to the x-axis of the coordinate system). Required if Outline Shape Type (0018,1630) is RECTANGULAR. See Section 10.38.1.2. |
|||
Y-coordinate in mm of the lower edge of the rectangular outline (parallel to the x-axis of the coordinate system). Required if Outline Shape Type (0018,1630) is RECTANGULAR. See Section 10.38.1.2. |
|||
Location (x,y) in mm of the center of the circular outline. Required if Outline Shape Type (0018,1630) is CIRCULAR. See Section 10.38.1.2. |
|||
Diameter in mm of the circular outline. Required if Outline Shape Type (0018,1630) is CIRCULAR. See Section 10.38.1.2. |
|||
Number of Vertices in Vertices of the Polygonal Outline (0018,1638). |
|||
A data stream of pairs of x and y in mm. Polygonal outlines are implicitly closed from the last vertex to the origin vertex and all edges shall be non-intersecting except at the vertices. Any given vertex shall occur only once in the data stream. Required if Outline Shape Type (0018,1630) is POLYGONAL. The number of pairs in this data stream shall equal the Value of Number of Polygonal Vertices (0018,1637). See Section 10.38.1.2. |
Table 10.39-1 specifies the Attributes of the Patient to Equipment Relationship Macro, which describes the position of the patient with respect to a device. The position is defined by means of a transformation matrix between a Patient Frame of Reference and an Equipment Frame of Reference.
Table 10.39-1. Patient to Equipment Relationship Macro Attributes
A rigid, homogeneous 4x4 transformation matrix that maps the patient coordinate space in the Frame of Reference used for the patient model to the coordinate system defined by the equipment. Matrix elements shall be listed in row-major order. See Section 10.39.1.1, Section 10.39.1.2 and Section C.7.6.21.1. |
|||
Comments entered by a human operator about the relationship between the patient Frame of Reference and the equipment. For display purposes only, shall not be used for other purposes. |
|||
Specific points in the patient coordinate system which further characterize the position of the patient with respect to the equipment. |
|||
Coordinate (x,y,z) in mm describing the location in the patient Frame of Reference that will be transformed to the Equipment Frame of Reference by using the Image to Equipment Mapping Matrix (0028,9520). |
|||
>>Include Table 8.8-1 “Code Sequence Macro Attributes”. |
|||
Actual Patient Support Position parameters. Shall be consistent with the Image to Equipment Mapping Matrix (0028,9520). See Section 10.39.1.2. |
|||
>Include Table 10.40-1 “Patient Support Position Macro Attributes”. |
A piece of equipment has an Equipment Coordinate System which can be used for expressing geometric concepts such as locations and orientations. The coordinate system is characterized by the location of the origin and the orientation of coordinate axes with respect to the equipment. The Equipment Coordinate System is a right-handed coordinate system.
Equipment Coordinate Systems are typically based on a standardized definition of axes. The choice of origin is often device-specific or device-type-specific. It may be any significant location on the machine such as the manufacturer-dependent machine isocenter.
The Equipment Coordinate System can be used as the parent for derived coordinate systems.
The Image to Equipment Mapping Matrix (0028,9520) describes the relationship between the Patient-oriented coordinate system and an Equipment Coordinate System. This matrix AM Bdescribes a rigid transformation of a point ( Bx, By, Bz) with respect to the Patient coordinate system into ( Ax, Ay, Az) with respect to the Equipment Coordinate System as defined in Section C.7.6.21.1.
The Equipment Coordinate System is identified by the Equipment Frame of Reference UID (300A,0675). For further information on the definition of the Equipment Frame of Reference, see Section 10.39.1.1. The patient-oriented coordinate system is identified by the Frame of Reference UID (0020,0052) of the SOP Instance it is used within. Both coordinate systems are expressed in millimeters.
The Patient Support Position Macro invoked by Patient Support Position Sequence (3006,00CB) allows the exchange of device-specific parameters for the patient support device. Applications designed to guide a specific patient support device will be able to de-compose the transformation into device-specific parameters or derive a transformation matrix out of these parameters. Applications that are unable to know the decomposition of the transformation to those parameters and vice versa will still be able to display the native labels and numerical values of those parameters to human readers.
The Patient Support Position Sequence (3006,00CB) may be present to annotate the matrix and display the decomposed matrix contents. The content of the Patient Support Position Macro shall be used for display purposes only. It shall not be used for other purposes. The content of this Macro shall not be used as a substitute for the Image to Equipment Mapping Matrix (0028,9520). In general, there is more than one way to reach the point in space that is described by the Image to Equipment Mapping Matrix (0028,9520). Hence it is explicitly not implied how this position is reached.
In some cases (e.g., emergency treatments in Radiotherapy), the Patient Frame of Reference is not defined by an image series. In this case an arbitrary Frame of Reference is used for the patient coordinate system in the Frame of Reference Module of the SOP Instance. The Image to Equipment Mapping Matrix (0028,9520) has the same meaning as in the case of image-based Patient Frame of Reference.
When a Frame of Reference of a patient model is not available, the well-known Frame of Reference of a patient support device may be used.
The well-known Frame of Reference and its origin and orientation with respect to the device shall be documented in the Conformance Statement. Note that the orientation of the axes of the well-known Frame of Reference are tied to the device and not to the patient.
As an example, the initial position needs to be specified for the patient setup, prior to any imaging. For a treatment table whose origin and orientation are defined by [IEC 61217], the well-known Frame of Reference UID "1.2.840.10008.1.4.3.3" may be used.
If the Image to Equipment Mapping Matrix (0028,9520) and the Patient Support Position Sequence (3006,00CB) are both present, the information in both locations shall be consistent.
Table 10.40-1 specifies the Attributes of the Patient Support Position Macro, which provides the device-specific geometric settings for the Patient Support device.
The information is intended for display to human readers and to support non-image-based patient positioning; however, the definition of the patient position with respect to the device is contained in the Image to Equipment Mapping Matrix (0028,9520).
Table 10.40-1. Patient Support Position Macro Attributes
Translational and rotational parameters for Patient Support devices. Required if Patient Support Position Specification Method (300A,065C) does not equal ABSENT. One or more Items shall be included in this Sequence if Patient Support Position Specification Method (300A,065C) equals DEVICE_SPECIFIC. Only one Item shall be included in this Sequence if Patient Support Position Specification Method (300A,065C) equals GLOBAL. |
|||
The Value of Device Index (3010,0039) in Patient Support Devices Sequence (300A,0686) corresponding to the Patient Support Device in use. Required if Patient Support Position Specification Method (300A,065C) equals DEVICE_SPECIFIC. |
|||
Index defining the order in which the Items in the Patient Support Position Device Parameter Sequence (300A,065D) are applied. The Value shall start at 1 and increase monotonically by 1. Required if Patient Support Position Specification Method (300A,065C) equals DEVICE_SPECIFIC. See Section 10.40.1. |
|||
Translational and rotational parameters for a particular Patient Support device. |
|||
Index defining the order in which the Items in the Patient Support Position Parameter Sequence (300A,065B) are applied. The Value shall start at 1 and increase monotonically by 1. Required if Patient Support Position Specification Method (300A,065C) equals DEVICE_SPECIFIC. See Section 10.40.1. |
|||
>>Include Table 10-2 “Content Item Macro Attributes”. |
The Device Order Index (300A,065E) and the Patient Support Position Parameter Order Index (300A,065F) are applied sequentially, meaning all the Items in a Patient Support Position Parameter Sequence (300A,065B) are applied before proceeding to the Item in the Patient Support Position Device Parameter Sequence (300A,065D) specified by the next Device Order Index (300A,065E) Value.
A vendor may specify codes that are not included in TID 175001 and/or a set of codes which is not identical with the set defined in Section 10.40.1.1 or Section 10.40.1.2. The vendor shall document the codes used in this Macro in the Conformance Statement, as well as the corresponding parameters, their geometric interpretation, and the order in which they will be applied. These parameters shall use UCUM units of mm for lengths and degrees for angles.
Devices using the [IEC 61217] coordinate systems to define geometric settings for the Patient Support device shall use the codes in Table 10.40-2 in the order specified in column Patient Support Position Parameter Order Index (300A,065F). Other codes shall not be used.
Devices using an isocentric representation to define geometric settings for the Patient Support device shall use the codes in Table 10.40-3 in the order specified in column Patient Support Position Parameter Order Index (300A,065F). Other codes shall not be used.
Table 10.41-1 specifies the Attributes of the General Procedure Protocol Reference Macro, which identifies the Procedure Protocol SOP Instance and the Protocol Element related to the creation of an Instance.
Because all the Instances in a Series are often generated from the same acquisition/reconstruction protocol, protocol is often considered at the Series level (Protocol Name (0018,1030) is in the General Series Module). It is however valid to have several Instances in the same Series where each Instance was generated using a different protocol and/or a different protocol element.
Table 10.41-1. General Procedure Protocol Reference Macro Attributes
Defined Procedure Protocol SOP Instance(s) that were used for this Instance. Required if this instance is a Performed Procedure Protocol that resulted from a Defined Procedure Protocol. May be present otherwise. One or more Items shall be included in this Sequence. See Section 10.41.1. |
|||
>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
A single Value corresponding to the Protocol Element Number (0018,9921) of the Acquisition Protocol Element Specification Sequence (0018,991F) that corresponds to this Instance. Shall not be present if Source Reconstruction Protocol Element Number (0018,993A) is present. |
|||
A single Value corresponding to the Protocol Element Number (0018,9921) of the Reconstruction Protocol Element Specification Sequence (0018,9933) that corresponds to this Instance. Shall not be present if Source Acquisition Protocol Element Number (0018,9938) is present. |
|||
Performed Procedure Protocol SOP Instance(s) that describe the conditions by which this Instance was generated. Required if a related Performed Procedure Protocol SOP Instance was created. One or more Items shall be included in this Sequence. See Section 10.41.1. |
|||
>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
A single Value corresponding to the Protocol Element Number (0018,9921) of the Acquisition Protocol Element Sequence (0018,9920) that corresponds to this Instance. Shall not be present if Source Reconstruction Protocol Element Number (0018,993A) is present. |
|||
A single Value corresponding to the Protocol Element Number (0018,9921) of the Reconstruction Protocol Element Sequence (0018,9934) that corresponds to this Instance. Shall not be present if Source Acquisition Protocol Element Number (0018,9938) is present. |
The Referenced Defined Protocol Sequence (0018,990C) contains a reference to the Defined Procedure Protocol SOP Instance(s) and protocol element that were used to generate this Instance. The Referenced Performed Protocol Sequence (0018,990D) contains a reference to the Performed Procedure Protocol SOP Instance(s) and protocol element that describe the conditions by which this Instance was generated.
Multiple Items in the Referenced Defined Protocol Sequence (0018,990C) may represent a group case where several Defined Procedure Protocols were performed together as a single Performed Procedure Protocol.
Multiple Items in the Referenced Performed Protocol Sequence (0018,990D) are recommended if the acquisition and reconstruction were recorded in separate Performed Procedure Protocol SOP Instances. However, it is not intended that this Sequence references Defined or prior Performed Protocol SOP Instances on which the current Performed Procedure Protocol SOP Instance was based. Such references may be found inside the current Performed Procedure Protocol SOP Instance itself.
In case where the acquisition and the reconstruction are done in two separate devices connected through the network, the reconstruction device can use the Source Acquisition Protocol Element of the Referenced Defined Protocol to determine the images that will be reconstructed with a given reconstruction protocol element.
Table 10.42-1 specifies the Attributes of the Hierarchical Evidence Reference Macro.
Table 10.42-1. Hierarchical Evidence Reference Macro Attributes
The Raw data that was used to derive this Image. One or more Items are permitted in this Sequence. NoteThe Items of in this Sequence may identify raw data that has not been stored or encoded as a DICOM object. This allows recognition that images and spectra in different Instances have been reconstructed from the same raw data. For such Items the Referenced SOP Class UID (0008,1150) may be "1.2.840.10008.5.1.4.1.1.66" (Raw Data Storage). |
|||
>Include Table C.17-3 “Hierarchical SOP Instance Reference Macro Attributes” |
|||
References to waveforms acquired in conjunction with this image. These Waveforms may or may not be temporally synchronized with this image. |
|||
>Include Table C.17-3 “Hierarchical SOP Instance Reference Macro Attributes” |
|||
Full set of Composite SOP Instances referred to inside the Referenced Image Sequences of this Instance. See Section 10.42.1.1 for further explanation. One or more Items shall be included in this Sequence. Required if the Referenced Image Sequence (0008,1140) is present and not empty, and the SOP Class UID (0008,0016) of the referencing SOP Instance is not a legacy converted SOP Class ("1.2.840.10008.5.1.4.1.1.2.2" (Legacy Converted Enhanced CT Image Storage), "1.2.840.10008.5.1.4.1.1.4.4" (Legacy Converted Enhanced MR Image Storage), "1.2.840.10008.5.1.4.1.1.128.1" (Legacy Converted Enhanced PET Image Storage)). May be present otherwise. |
|||
>Include Table C.17-3 “Hierarchical SOP Instance Reference Macro Attributes” |
|||
Full set of Composite SOP Instances referred to inside the Source Image Sequences of this Instance. See Section 10.42.1.1 for further explanation. One or more Items shall be included in this Sequence. Required if the Source Image Sequence (0008,2112) is present and not empty, and the SOP Class UID (0008,0016) of the referencing SOP Instance is not a legacy converted SOP Class ("1.2.840.10008.5.1.4.1.1.2.2" (Legacy Converted Enhanced CT Image Storage), "1.2.840.10008.5.1.4.1.1.4.4" (Legacy Converted Enhanced MR Image Storage), "1.2.840.10008.5.1.4.1.1.128.1" (Legacy Converted Enhanced PET Image Storage)). May be present otherwise. |
|||
>Include Table C.17-3 “Hierarchical SOP Instance Reference Macro Attributes” |
|||
References to Presentation State instances created together with this instance NoteThis Sequence does not reference Presentation States generated after image creation, such as during interpretation. One or more Items shall be included in this Sequence. Required if Presentation State is created together with the images. |
|||
>Include Table C.17-3 “Hierarchical SOP Instance Reference Macro Attributes” |
Each Composite IOD is composed of the following Sections
Optionally, a Functional Group Macros Table used by the Multi-frame Functional Groups Module
Section A.1.1, Section A.1.2 and Section A.1.3 define the requirements of a) through d) above.
This Section of an IOD provides the Entity-Relationship (E-R) Model that depicts the relationships of the components or Information Entities (IE) of the specified IOD. It forms an IOD specific information model. This E-R model provides the complete context of how the Composite Instance information shall be interpreted when a Composite Instance is exchanged between two DICOM Application Entities; in particular, an IOD will specify a single IE at the level below the Series IE.
Even though Composite Instances are encoded as discrete individual components, each Composite Instance IOD E-R Model requires that all Composite Instances that are part of a specific Study shall share the same context. That is, all Composite Instances within a specific Patient Study share the same Patient and Study information; all Composite Instances within the same Series share the same Series information; etc.
Figure A.1-1 is the DICOM Composite Instance IOD Information Model. It applies to all Patient-related Composite Instance IODs defined in Annex A. However, a subset of this model may be specified by each individual Composite Instance IOD to accurately define the context for specific Composite Instance exchange.
The sub-sections of this Section describe the Information Entities (IE) that comprise the Composite Instance IODs defined in this Annex.
The Patient IE defines the characteristics of a Patient who is the subject of one or more medical Studies.
The Study IE defines the characteristics of a medical Study performed on a Patient. A Study is a collection of one or more Series of medical images, presentation states, and/or SR documents that are logically related for the purpose of diagnosing a Patient. Each Study is associated with exactly one Patient.
A Study may include Composite Instances that are created by a single modality, multiple modalities or by multiple devices of the same modality.
The Series IE defines the Attributes that are used to group Composite Instances into distinct logical sets. Each Series is associated with exactly one Study.
The following criteria group Composite Instances into a specific Series:
All Composite Instances within a Series must be of the same modality
Each Series may be associated with exactly one Frame of Reference IE, and if so associated all Composite Instances within the Series shall be spatially or temporally related to each other
All Composite Instances within the Series shall be created by the same equipment; therefore, each Series is associated with exactly one Equipment IE
All Composite Instances within a Series shall have the same Series information
Presentation States shall be grouped into one or more Series without Images or Waveforms (i.e., in a different Series from the Series containing the Images or Waveforms to which they refer).
The Series containing Grayscale, Color and Pseudo-Color Softcopy Presentation States and the Series containing the Images to which they refer are both contained within the same Study, except for Blended Presentation States, which may refer to images from different Studies.
The Series containing the Waveform Presentation State and the Series containing the Waveforms to which they refer are both contained within the same Study.
The Series containing the Waveform Presentation State and the Series containing Waveform Annotation SRs to which they refer are both contained in the same Study but in different Series.
Waveforms shall be grouped into Series without Images. A Frame of Reference IE may apply to both Waveform Series and Image Series.
SR Documents shall be grouped into Series without Images. The Frame of Reference IE may apply to SR Document Series, for SR Documents that contain 3D spatial coordinates relative to one or more spatial Frames of Reference, or temporal coordinates that require a temporal Frame of Reference.
The Equipment IE describes the particular device that produced the Series of Composite Instances. A device may produce one or more Series within a Study. The Equipment IE does not describe the data acquisition or image creation Attributes used to generate the Composite Instances within a Series. These Attributes are described in the Composite Instance specific IEs (e.g., the Image IE).
The Frame of Reference IE identifies the coordinate system that conveys spatial and/or temporal information of Composite Instances in a Series.
When present, a Frame of Reference IE may be related to one or more Series. In this case, it provides the ability to spatially or temporally relate multiple Series to each other. In such cases, the Series may share the UID of the Frame of Reference, or alternatively, a Registration SOP Instance may specify the spatial relationship explicitly, as a spatial transformation. A Frame of Reference IE may also spatially register a Frame of Reference to an atlas.
The Image IE defines the Attributes that describe the pixel data of an image. The pixel data may be generated as a direct result of Patient scanning (termed an Original Image) or the pixel data may be derived from the pixel data of one or more other images (termed a Derived Image). An image is defined by its image plane, pixel data characteristics, gray scale and/or color mapping characteristics and modality specific characteristics (acquisition parameters and image creation information).
An image is related to a single Series within a single Study.
The pixel data within an Image IE may be represented as a single Frame of pixels or as multiple Frames of pixel data. The Frames of a Multi-frame Image (a Cine Run or the slices of a volume) are sequentially ordered and share a number of common properties. A few Attributes may vary between Frames (e.g., Time, Angular Displacement, Slice Increment). All common Image IE Attributes refer to the first Frame of a Multi-frame Image.
Overlay, Modality and Value of Interest Lookup Table and Real World Value Mapping data may be included within an Image IE only if this information is directly associated with the image.
Overlay data represents graphics or text in a bit-map format, and is used to indicate such items as region of interest, reference marks and annotations.
Modality LUT data describes the transformation of manufacturer dependent pixel values into pixel values that are manufacturer independent (e.g., Hounsfield units for CT, Optical Density for film digitizers, etc.). The transformation may be linear, described by Rescale Slope (0028,1053) and Rescale Intercept (0028,1052), or non-linear, described by a Lookup Table (LUT).
The Value of Interest (VOI) LUT data describes the transformation of the modality pixel values into pixel values that are meaningful for print, display, etc. This transformation is applied after any Modality LUT. The transformation may be linear, described by Window Center and Window Width, or non-linear, described by a Lookup Table. A non-linear interpretation of Window Center and Window Width may be defined by VOI LUT Function.
The Real World Value Mapping data describes the transformation of the image pixel values into Real World Values in defined units. There may be multiple transformations, each scoped by a range of input pixel values. Each transformation may be linear, described by Slope and Intercept, or non-linear, described by a Lookup Table.
Retired. See PS3.3-2016a.
Overlays were previously modeled as independent Information Entities; in the current model they are considered Attributes within the Image IE or Presentation State IE. See A.1.2.6.1.
Retired. See PS3.3-2004.
Retired. See PS3.3-2016a.
Modality LUTs were previously modeled as independent Information Entities; in the current model they are considered Attributes within the Image IE or Presentation State IE. See A.1.2.6.2.
Retired. See PS3.3-2016a.
VOI LUTs were previously modeled as independent Information Entities; in the current model they are considered Attributes within the Image IE or Presentation State IE. See A.1.2.6.3.
The Presentation State IE defines how a referenced image (or images) will be presented (e.g., displayed) in a device independent grayscale space (i.e., in P-Values) or color space (i.e., in PCS-values), and what graphical annotations and spatial and grayscale contrast transformations will be applied to the referenced image pixel data.
Overlay, Modality LUT, and VOI LUT data (see A.1.2.6.1, A.1.2.6.2, and A.1.2.6.3) may be included within a Presentation State IE if this information is to be applied to the referenced image(s).
The Waveform IE represents a multi-channel time-based digitized waveform. The waveform consists of measurements of some physical qualities (e.g., electrical voltage, pressure, gas concentration, or sound), sampled at constant time intervals. The measured qualities may originate, for example, in any of the following sources:
The sample data within a Waveform IE may represent one or more acquired channels. Several signal channels acquired at the same sampling rate can be multiplexed (by interleaving samples) in a single multiplex group. (see also Annex C “Waveforms (Informative)” in PS3.17.)
The SR Document IE defines the Attributes that describe the content of an SR Document. These include semantic context as well as Attributes related to document completion, verification and other characteristics. An SR Document SOP Instance is related to a single Series within a single Study.
The Spectroscopy IE defines the Attributes that describe the data of a spectroscopy acquisition created by a magnetic resonance spectroscopy device.
The Raw Data IE defines the Attributes that describe a collection of data that may be used for further processing to produce image data or other data.
The Encapsulated Document IE defines the Attributes that describe the content of a non-DICOM formatted document that is encapsulated in a DICOM Attribute. These include Attributes related to document origin, title, and other characteristics. An Encapsulated Document SOP Instance is related to a single Series within a single Study.
The Real World Value Mapping IE defines the Attributes that describe the mapping of stored pixel data to Real World values (see A.1.2.6.4).
The Surface IE defines the Attributes that describe a surface in a spatial coordinate system. A surface is defined by its shape and can be further defined by normals on that shape. The surface may be reconstructed from either spatial scans (e.g., laser scanners) or based on images. A surface is described by its finite volume and manifold property, gray scale and color mapping characteristics, presentation type, opacity, and modality specific characteristics.
The Measurements IE defines the Attributes that describe the measurements taken by medical instruments.
The Tractography Results IE defines the Attributes that describe the results of a tractography application.
The Plan IE defines the parameters and instructions to deliver treatment, particularly Radiotherapy, to the Patient. The entity includes the set of machine and positioning parameters to be applied during treatment delivery and instructions guiding the treatment workflow.
The Content Assessment Result IE contains the results of an assessment of the content of a SOP Instance.
An assessment is part of a process within a clinical workflow, conducted by users or devices, which have the role of assessing the validity and suitability of the content in question, based on subjective or objective criteria. The specific nature of such a process is outside of the scope of this Standard.
The Spatial Fiducials IE identifies one or more geometric locations or shapes within a Frame of Reference or image pixel/voxel space that may be correlated with similar locations or shapes within different Frames of Reference or image pixel/voxel spaces.
The Dose IE describes dose distributions calculated by radiotherapy treatment planning systems. These distributions may be represented as 2D or 3D grids, as isodose curves, or as named or unnamed dose points scattered throughout a volume.
The Structure Set IE describes Regions of Interest (ROI) within a referenced 2D (image) or 3D (volumetric) space. These ROIs may be represented as geometric contours.
The Procedure Protocol IE defines the Attributes that describe a Protocol. This IE may encode a Defined Procedure Protocol or a Performed Procedure Protocol.
The Acquisition IE defines the Attributes that describe a single continuous gathering of data.
An Acquisition may result in more than one Series, and a Series may contain Instances from more than one Acquisition.
The Multi-Resolution Pyramid IE describes a set of Images that encode the same image data at different spatial resolutions, i.e., a base (highest resolution) layer that is successively smoothed and down-sampled to create additional lower resolution layers (a multi-resolution decomposition).
No specific method of filtering or down-sampling is specified by the Standard, nor is there a requirement for any specific down-sampling factor between layers, nor that an integer factor be used.
Each layer is encoded as a separate DICOM Image, each of which has a uniform resolution (same Value for Pixel Spacing (0028,0030)). Layers may be tiled, with each tile encoded as a Frame of a Multi-frame Image.
All DICOM Image SOP Instances that constitute a single Multi-Resolution Pyramid shall share the same Frame of Reference, and shall be contained in the same Series.
Only one Multi-Resolution Pyramid shall be contained in a Series (i.e., each such Multi-Resolution Pyramid will be in a different Series).
In historical usage, there is no Multi-Resolution Pyramid IE and thus a Series is not constrained to contain only a single conceptual pyramid. However, any instantiation of the Multi-Resolution Pyramid in a Series constrains the Series to one Multi-Resolution Pyramid.
Each Multi-Resolution Pyramid may be accompanied in the same Series by LABEL, OVERVIEW and THUMBNAIL images if they share the same Frame of Reference (but not otherwise, per the definition of the Series IE). The THUMBNAIL image rather than a VOLUME image may be the apex (lowest resolution layer) of the Multi-Resolution Pyramid.
A unique identifier, Pyramid UID (0008,0019) will be assigned to an instance of a Multi-Resolution Pyramid, and will be shared by all of the layers that constitute that instance of a Multi-Resolution Pyramid, whether or not a particular resolution layer (usually the highest resolution) is deemed to be ORIGINAL, and the lower resolution layers DERIVED (e.g., by some down-sampling image processing operation). By definition, the absence of Pyramid UID (0008,0019) implies the absence of instantiation of the Multi-Resolution Pyramid IE.
That use is distinct from the Pyramid UID (0008,0019) of different Multi-Resolution Pyramids that may be further derived from a Multi-Resolution Pyramid. In otherwords, the Pyramid UID (0008,0019) of a Multi-Resolution Pyramid will not be shared between two pyramids that contain different pixel data (other than differences due to lossless representation of the same pixel data in different Transfer Syntaxes).
The Waveform Presentation State IE defines how referenced waveforms will be presented.
The Waveform Presentation State IE comprises text annotations, segments of interest, and montages including filters, colors, gain, and vertical sizes of waveform channels if this information is to be applied to the referenced waveform(s). It might also contain display information for structured annotations related to the referenced waveform(s).
This Section of each IOD defines in a tabular form the Modules comprising the IOD. The following information must be specified for each Module in the table:
A reference to the Section in Annex C that defines the Module or Functional Group
The usage of the Module or Functional Group; whether it is:
Mandatory (see Section A.1.3.1), abbreviated M
Conditional (see Section A.1.3.2), abbreviated C
User Option (see Section A.1.3.3), abbreviated U
The Modules referenced are defined in Annex C.
For each IOD, Mandatory Modules shall be supported per the definitions, semantics and requirements defined in Annex C.
Conditional Modules are Mandatory Modules if specific conditions are met. If the specified conditions are not met, this Module shall not be supported; that is, no information defined in that Module shall be present.
User Option Modules may or may not be supported. If an optional Module is supported, the Attribute Types specified in the Modules in Annex C shall be supported.
The Tables in this Section provide an overview of the Modules used throughout the Composite IODs. This table is for informative purposes only. It is based on the IOD definitions found in the remaining Sections of Annex A that are normative.
* The notation next to M and U indicates a special condition for these Modules. Refer to the corresponding IODs in this Annex for details.
The original Ultrasound Image IOD and Ultrasound Multi-frame IOD, and the associated Ultrasound Image Storage SOP Class UID and Ultrasound Multi-frame Image Storage SOP Class UID have been retired. A new Ultrasound Image IOD and a new Ultrasound Multi-frame Image IOD are defined, as shown in Table A.1-1a, which includes the Palette Color Lookup Table Module.
The original Nuclear Medicine Image IOD and the associated Nuclear Medicine Image Storage SOP Class UID have been retired. A completely new Nuclear Medicine Image IOD is defined, as shown in Table A.1-1a.
Table A.1-1d. Composite Information Object Modules Overview - More Images
Table A.1-3. Composite Information Object Modules Overview - More Non-Images
The Computed Radiography Image IOD specifies an image that has been created by a computed radiography imaging device.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE. The Frame of Reference IE is not a component of this IOD.
Table A.2-1 specifies the Modules of the Computed Radiography Image IOD.
The Curve Module (Retired) was previously included in the Image IE for this IOD but has been retired. See PS3.3-2004.
The CT Image IOD specifies an image that has been created by a Computed Tomography imaging device.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.3-1 specifies the Modules of the CT Image IOD.
If Multi-energy CT Acquisition (0018,9361) is YES the following constraints will apply:
The Contrast/Bolus Module shall be present if contrast was administered even if images are processed to remove contrast information from the pixels, e.g. Virtual Non-Contrast images.
The Real World Value Mapping Sequence (0040,9096) shall be present in the General Image Module.
For Measurement Units Code Sequence (0040,08EA) in the Real World Value Mapping Sequence (0040,9096) DCID 301 “Multi-energy Material Unit” shall be used.
The MR Image IOD specifies an image that has been created by a Magnetic Resonance imaging device.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
The Nuclear Medicine Image IOD specifies an image that has been created by a Nuclear Medicine (NM) imaging device. This includes data created by external detection devices that create images of the distribution of administered radioactive materials in the body. Depending on the specific radio pharmaceutical administered and the particular imaging procedure performed, problems involving changes in metabolism, function, or physiology can be investigated and various regional pathologies can be studied.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.5-1 specifies the Modules of the Nuclear Medicine Image IOD.
Table A.5-1. Nuclear Medicine Image IOD Modules
U - See Section A.5.4.1 |
|||
C - Required if Image Type (0008,0008) Value 3 is TOMO, GATED TOMO, RECON TOMO or RECON GATED TOMO |
|||
C - Required if Image Type (0008,0008) Value 3 is GATED, GATED TOMO, or RECON GATED TOMO |
|||
C - Required if Image Type (0008,0008) Value 3 is RECON TOMO or RECON GATED TOMO |
|||
C - Required if the SOP Instance was created in response to a Frame-Level retrieve request |
The Curve Module (Retired) was previously included in the Image IE for this IOD but has been retired. See PS3.3-2004.
For Acquisition Context Sequence (0040,0555) DTID 3470 “NM/PET Acquisition Context” shall be used, which includes description of the cardiovascular rest or stress state.
The Acquisition Context Sequence (0040,0555) shall always apply to all Frames in the Image. Patient State shall always apply to all Frames in the Image, therefore, neither Referenced Frame Numbers (0040,A136) nor Referenced Frame Number (0008,1160) shall be present.
The Acquisition Context information may be entered during acquisition, or obtained from the Modality Worklist using information supplied in the Protocol Context, using TID 15101 “NM/PET Protocol Context”.
The Ultrasound Image IOD specifies an image that has been created by an Ultrasound (US) imaging device.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.6-1 specifies the Modules of the Ultrasound Image IOD.
Table A.6-1. Ultrasound Image IOD Modules
The US Frame of Reference Module was previously included in this IOD, but has been retired. See PS3.3-2003.
A Curve IE was previously included in this IOD that was mutually exclusive with the Image IE, but has been retired. See PS3.3-2004.
For the purpose of conveying ultrasound protocol data management information it is recommended that the Performed Protocol Code Sequence (0040,0260) be assigned the code value(s) of the performed ultrasound protocol, if any. For Performed Protocol Code Sequence (0040,0260) BCID 12001 “Ultrasound Protocol Type” may be used.
The Ultrasound Multi-frame Image IOD specifies a Multi-frame Image that has been created by an ultrasound imaging device.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.7-1 specifies the Modules of the Ultrasound Multi-frame Image IOD.
Table A.7-1. Ultrasound Multi-frame Image IOD Modules
The US Frame of Reference Module was previously included in this IOD, but has been retired. See PS3.3-2003.
A Curve IE was previously included in this IOD that was mutually exclusive with the Image IE, but has been retired. See PS3.3-2004.
For the purpose of conveying ultrasound protocol data management information it is recommended that the Performed Protocol Code Sequence (0040,0260) be assigned the code value(s) of the performed ultrasound protocol, if any. For Performed Protocol Code Sequence (0040,0260) BCID 12001 “Ultrasound Protocol Type” may be used.
The Overlay Plane Module and Multi-Frame Overlay Module may be used to describe the active image area by use of a either a single frame overlay that applies to all image Frames, or per-frame overlays. In either case, an Overlay Type (60xx,0040) Value of R and an appropriate Overlay Subtype (60xx,0045) Value is used. In the case of a single frame overlay that applies to all image Frames, the active area specified by such an active image area overlay will be at the same location in every Frame of the image as specified in Section C.9.2 Overlay Plane Module.
The Secondary Capture Image IODs specify images that are converted from a non-DICOM format to a modality independent DICOM format.
Examples of types of equipment that create Secondary Capture (SC) Images include:
Video interfaces that convert an analog video signal into a digital image
Digital interfaces that are commonly used to transfer non-DICOM digital images from an imaging device to a laser printer
Film digitizers that convert an analog film image to digital data
Workstations that construct images that are encoded as a screen dump
Scanned documents and other bitmap images including hand-drawings
Synthesized images that are not modality-specific, such as cine-loops of 3D reconstructions
Originally, one relatively unconstrained, single-frame, Secondary Capture Image IOD was defined in the DICOM Standard. Though this IOD is retained and not retired since it is in common use, more specific IODs for particular categories of application are also defined.
The following IODs are all multi-frame. A Single-frame Image is encoded as a Multi-frame Image with only one Frame. The multi-frame Secondary Capture Image IODs consist of:
The Secondary Capture Image IOD specifies Single-frame Images that are converted from a non-DICOM format to a modality independent DICOM format, without any constraints on pixel data format.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE. The Frame of Reference IE is not a component of this IOD.
Table A.8-1 specifies the Modules of the Secondary Capture Image IOD.
Table A.8-1. Secondary Capture Image IOD Modules
If Image Position (Patient) (0020,0032) and Image Orientation (Patient) (0020,0037) (from the Image Plane Module) are present, then the Values of Pixel Spacing (0028,0030) (from the Image Plane Module and the Basic Pixel Spacing Calibration Macro included from the SC Image Module) are intended to be used for 3D spatial computations, rather than any Values of Nominal Scanned Pixel Spacing (0018,2010) (from the SC Image Module), which may also be present.
The Multi-frame Single Bit Secondary Capture Image IOD specifies images that are converted from a non-DICOM format to a modality independent DICOM format.
This IOD is typically used for scanned documents and bitmap images of hand drawings.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.8-2 specifies the Modules of the Multi-frame Single Bit Secondary Capture Image IOD.
Table A.8-2. Multi-frame Single Bit Secondary Capture Image IOD Modules
In the Image Pixel Module, the following constraints apply:
As a consequence of these Attribute Values, single bit pixels are packed eight to a byte as defined by the encoding rules in PS3.5.
The VOI LUT Module shall not be present.
The Overlay Plane Module shall not be present.
The Multi-frame Grayscale Byte Secondary Capture Image IOD specifies Grayscale Byte images that are converted from a non-DICOM format to a modality independent DICOM format.
This IOD is typically used for screen captured images for modalities that have pixel values of 8 bits, but may also be appropriate for scanned grayscale documents.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.8-3 specifies the Modules of the Multi-frame Grayscale Byte Secondary Capture Image IOD.
Table A.8-3. Multi-frame Grayscale Byte Secondary Capture Image IOD Modules
The VOI LUT Module is required if the VOI LUT stage is not an identity transformation. Support for both window and LUT is mandatory. The output grayscale space is defined to be in P-Values.
If the VOI LUT Module is absent, then the stored pixel values are in P-Values.
In the Image Pixel Module, the following constraints apply:
In the SC Multi-frame Image Module, the following constraints apply:
The Overlay Plane Module shall not be present.
Table A.8-3b specifies the use of the Functional Group Macros used in the Multi-frame Functional Groups Module for the Multi-frame Grayscale Byte Secondary Capture Image IOD.
Table A.8-3b. Multi-frame Grayscale Byte Secondary Capture Image Functional Group Macros
If the Pixel Measures Macro is present, then the Values of Pixel Spacing (0028,0030) therein are intended to be used for 3D spatial computations, rather than any Values of Nominal Scanned Pixel Spacing (0018,2010) (from the SC Multi-frame Image Module), which may also be present.
The Multi-frame Grayscale Word Secondary Capture Image IOD specifies Grayscale Word images that are converted from a non-DICOM format to a modality independent DICOM format.
This IOD is typically used for screen captured images for modalities that have pixel values greater than 8 bits.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.8-4 specifies the Modules of the Multi-frame Grayscale Word Secondary Capture Image IOD.
Table A.8-4. Multi-frame Grayscale Word Secondary Capture Image IOD Modules
The VOI LUT Module is required if the VOI LUT stage is not an identity transformation. Support for both window and LUT is mandatory. The output grayscale space is defined to be in P-Values.
If the VOI LUT Module is absent, then the stored pixel values are in P-Values.
In the Image Pixel Module, the following constraints apply:
Rescale Slope (0028,1053) and Rescale Intercept (0028,1052) are not constrained in this IOD to any particular values. E.g., they may be used to recover floating point values scaled to the integer range of the stored pixel values, Rescale Slope (0028,1053) may be less than one, e.g., a Rescale Slope (0028,1053) of 1.0/65535 would allow represent floating point values from 0 to 1.0.
The Overlay Plane Module shall not be present. Unused high bits shall be filled with zeroes.
Table A.8-4b specifies the use of the Functional Group Macros used in the Multi-frame Functional Groups Module for the Multi-frame Grayscale Word Secondary Capture Image IOD.
Table A.8-4b. Multi-frame Grayscale Word Secondary Capture Image Functional Group Macros
If the Pixel Measures Macro is present, then the Values of Pixel Spacing (0028,0030) therein are intended to be used for 3D spatial computations, rather than any Values of Nominal Scanned Pixel Spacing (0018,2010) (from the SC Multi-frame Image Module), which may also be present.
The Multi-frame True Color Secondary Capture Image IOD specifies True Color images that are converted from a non-DICOM format to a modality independent DICOM format.
This IOD is typically used for screen captured or synthetic images where true color is used, but may also be appropriate for scanned color documents.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.8-5 specifies the Modules of the Multi-frame True Color Secondary Capture Image IOD.
Table A.8-5. Multi-frame True Color Secondary Capture Image IOD Modules
The VOI LUT Module shall not be present.
In the Image Pixel Module, the following constraints apply:
Photometric Interpretation (0028,0004) shall be RGB for uncompressed or lossless compressed Transfer Syntaxes that do not have defined color space transformations, YBR_ICT for irreversible JPEG 2000 Transfer Syntaxes, YBR_RCT for reversible JPEG 2000 Transfer Syntaxes, YBR_PARTIAL_420 for MPEG2, MPEG-4 AVC/H.264, HEVC/H.265 Transfer Syntaxes and YBR_FULL_422 for JPEG lossy compressed Transfer Syntaxes and YBR_FULL or RGB for RLE Transfer Syntaxes
Planar Configuration (0028,0006) shall be 0 (color-by-pixel) if Photometric Interpretation (0028,0004) is RGB
The Overlay Plane Module shall not be present.
For images being referenced as texture maps that are not clinical images, a modality Value of TEXTUREMAP may be used as the Value of Modality (0008,0060).
Table A.8-5b specifies the use of the Functional Group Macros used in the Multi-frame Functional Groups Module for the Multi-frame True Color Secondary Capture Image IOD.
Table A.8-5b. Multi-frame True Color Secondary Capture Image Functional Group Macros
If the Pixel Measures Macro is present, then the Values of Pixel Spacing (0028,0030) therein are intended to be used for 3D spatial computations, rather than any Values of Nominal Scanned Pixel Spacing (0018,2010) (from the SC Multi-frame Image Module), which may also be present.
Retired. See PS3.3-2004.
Retired. See PS3.3-2004.
Retired. See PS3.3-2004.
Retired. See PS3.3-2004.
Retired. See PS3.3-2004.
This Section defines the Information Object for single plane X-Ray Angiographic (XA) Imaging that includes those Attributes and Information Objects necessary for the interchange of digital X-Ray Angiographic data. This includes images of the heart and all blood vessels.
The X-Ray Angiographic Image IOD share a significant amount of common information with the XRF IOD. The differences between the two IODs are that the XRF Image IOD includes a tomography Module; and the two IODs utilize different methods to specify positioner angles. The XRF Image IOD contains a single column angulation Data Element that uses an Equipment-Based Coordinate System, while X-Ray Angiographic Image IOD c-arm positioner angles are specified in a Patient-Based Coordinate System. RF applications that support a Patient-Based Coordinate System with cranial/caudal, LAO/RAO angles may utilize the X-Ray Angiographic Image IOD.
The X-Ray Angiographic Image IOD is also applicable to clinical areas other than angiography (e.g., Interventional Procedures, Myelography, Biopsy/Localization, and Neurology).
For the purpose of X-Ray Angiography (XA), this IOD can be used to encode a Single-frame Image, or a Cine Run encoded in a single Multi-frame Image.
A typical Study might include all the images generated between the time a Patient gets on and gets off the procedure table. As several separable diagnostic or therapeutic processes may occur during a single Study (e.g., pre-intervention CA, left ventriculography, and post-intervention CA), a Series may be defined as comprising a set of images (single or multi-frame) associated with one such process within a Study.
This IOD can be used to encode a single plane acquisition, or one plane of a biplane acquisition.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.14-1 specifies the Modules of the X-Ray Angiographic Image IOD.
Table A.14-1. X-Ray Angiographic Image IOD Modules
The Curve Module (Retired) was previously included in the Image IE for this IOD but has been retired. See PS3.3-2004.
The focus for this X-Ray Radiofluoroscopic Image IOD is to address the requirements for image transfer found in general Radiofluoroscopic applications performed on a table with a column. For applications performed on X-Ray RF acquisition systems that support a Patient-Based Coordinate System with cranial/caudal, LAO/RAO angles, etc. the X-Ray Angiographic Image IOD may be used.
An example of a case where the X-Ray Angiographic Image IOD may be preferred to the RF IOD are RF acquisition system equipped with an X-Ray source and an image Receptor positioned by what is generally called a c-arm (e.g., Interventional Procedures, Myelography, Biopsy, and Neurology).
This Section defines the Information Object for X-Ray Radiofluoroscopic (XRF) Imaging that includes those Attributes and Information Objects necessary for the interchange of digital X-Ray RF Image data. The XRF IOD is applicable to X-Ray acquisition systems equipped with an image receptor whose plane is parallel to the table plane where the Patient is. This Table has in general the ability to be tilted. Furthermore the X-Ray source may be supported by a column that can be angulated to adjust the incidence of the X-Ray beam on the image receptor plan. An equipment based coordinated system is used to track these angles.
For the purpose of X-Ray Radiofluoroscopy, this IOD can be used to encode a Single-frame Image, or a Cine Run encoded in a single Multi-frame Image.
A typical Study might include all the images generated between the time a Patient gets on and gets off the procedure table. As several separable diagnostic or therapeutic processes may occur during a single Study, a Series may be defined as comprising a set of images (single or multi-frame) associated with one such process within a Study.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.16-1 specifies the Modules of the X-Ray Radiofluoroscopic Image IOD.
Table A.16-1. X-Ray Radiofluoroscopic Image IOD Modules
The Curve Module (Retired) was previously included in the Image IE for this IOD but has been retired. See PS3.3-2004.
The focus for this RT Image IOD is to address the requirements for image transfer found in general Radiotherapy (RT) applications performed on conventional simulators, virtual simulators, and portal imaging devices. Such images have a conical imaging geometry and may either be acquired directly from the device, or digitized using a film digitizer. Numeric beam data parameters may also be recorded with the image, indicating the parameter values at the time the image was taken or created.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.17.3-1 specifies the Modules of the RT Image IOD.