PS 3.3-2007 Digital Imaging and Communications in Medicine (DICOM) Part 3: Information Object Definitions Published by National Electrical Manufacturers Association 1300 N. 17th Street Rosslyn, Virginia 22209 USA © Copyright 2007 by the National Electrical Manufacturers Association. All rights including translation into other languages, reserved under the Universal Copyright Convention, the Berne Convention for the Protection of Literacy and Artistic Works, and the International and Pan American Copyright Conventions. NOTICE AND DISCLAIMER 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. CONTENTS FOREWORD The American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) formed a joint committee to develop a standard for Digital Imaging and Communications in Medicine (DICOM). This DICOM Standard was developed according to the NEMA procedures. This standard is developed in liaison with other standardization organizations including CEN TC251 in Europe and JIRA in Japan, with review also by other organizations including IEEE, HL7 and ANSI in the USA. The DICOM Standard is structured as a multi-part document using the guidelines established in the following document:  ISO/IEC Directives, 1989 Part 3 : Drafting and Presentation of International Standards. This document is one part of the DICOM Standard which consists of the following parts: PS 3.1: Introduction and Overview PS 3.2: Conformance PS 3.3: Information Object Definitions PS 3.4: Service Class Specifications PS 3.5: Data Structures and Encoding PS 3.6: Data Dictionary PS 3.7: Message Exchange PS 3.8: Network Communication Support for Message Exchange PS 3.9: Retired PS 3.10: Media Storage and File Format for Media Interchange PS 3.11: Media Storage Application Profiles PS 3.12: Formats and Physical Media PS 3.13: Retired PS 3.14: Grayscale Standard Display Function PS 3.15: Security and System Management Profiles PS 3.16: Content Mapping Resource PS 3.17: Explanatory Information PS 3.18: Web Access to DICOM Persistent Objects (WADO) These parts are related but independent documents. Their development level and approval status may differ. Additional parts may be added to this multi-part standard. PS 3.1 should be used as the base reference for the current parts of this standard. 1 Scope and field of application This Part of the DICOM Standard specifies the set of Information Object Definitions (IODs) which provide an abstract definition of real-world objects applicable to communication of digital medical information. For each IOD, this Part specifies:  any necessary information for the semantic description of the IOD  relationships to associated real-world objects relevant to the IOD  Attributes which describe the characteristics of the IOD For each IOD, this Part does not specify:  the nature of any Service Class Definition intended to reference the IOD  the nature of any interactions which result in the usage of the IOD This Part is related to other parts of the DICOM Standard in that:  PS 3.4, Service Class Specifications, specifies application level services by grouping DIMSE services with IODs as defined in this Part;  PS 3.5, Data Structure and Semantics, defines the data encoding used in the DIMSE Protocol when applied to IODs defined in this Part;  PS 3.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;  PS 3.7, Message Exchange Protocol, defines the DIMSE Services and Protocol which may be applied to IODs defined in this Part. 2 Normative references The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO) AND INTERNATIONAL ELECTROTECHNICAL COMMISSION (IEC) ISO/IEC Directives, 1989 Part 3 Drafting and Presentation of International Standards ISO/IEC 2022:1994 Information technology - Character code structure and extension techniques. ISO 3950-1984 Dentistry - Designation system for teeth and areas of the oral cavity. 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 Note: 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 10118-3:1998 Information technology – Security techniques – Hash-functions – Part 3: Dedicated hash-functions (RIPEMD-160 reference) Note: The draft RIPEMD-160 specification and sample code are also available at http://homes.esat.kuleuven.be/~bosselae/ripemd160.html ISO/IEC 10646:2003 Information Technology -- Universal Multiple-Octet Coded Character Set (UCS) Note: ISO/IEC 10646-2003 is the same as Unicode Version 4.0, available at http://unicode.org 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 15076-1:2005 Image technology colour management — Architecture, profile format, and data structure Note: Also available as ICC.1:2004-10 (Profile version 4.2.0.0), International Color Consortium. IEC 60601-2-44, Ed.2.1 Medical Electrical Equipment – Part 2-44: Particular Requirements for the Safety of X-Ray Equipment for Computed Tomography, 2002 IEC 61217, Ed 1.1 Radiotherapy Equipment - Coordinates, Movements and Scales, 2002 IEC 61966-2.1 Multimedia systems and equipment - Colour measurement and management– Part 2.1: Colour management - Default RGB colour space – sRGB, 1999 INTERNATIONAL TELECOMMUNICATIONS UNION (ITU) ITU-T G.711 Pulse code modulation (PCM) of voice frequencies, 1998 ITU-T X.509 Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks, 2000 Note: 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. INTERNET ENGINEERING TASK FORCE (IETF) RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, November 1996 RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax RFC 2437 PKCS #1 RSA Cryptography Specifications Version 2.0 Note: 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. RFC 2630 Cryptographic Message Syntax, June 1999 RFC 3161 Internet X.509 Public Key Infrastructure; Time Stamp Protocols HEALTH LEVEL SEVEN (HL7) ANSI/HL7 V2.5-2003 HL7 Standard Version 2.5 – An Application Protocol for Electronic Data Exchange in Healthcare Environments ANSI/HL7 v3 DT R1-2004 Health Level Seven Version 3 Standard: Data Types – Abstract Specification, Release 1 ANSI/HL7 CDA R1.0-2000 Health Level Seven Version 3 Standard: Clinical Document Architecture Framework, Release 1.0 ANSI/HL7 v3 CDA R2-2005 Health Level Seven Version 3 Standard: Clinical Document Architecture Framework, Release 2 HL7 SCTP R1.0 HL7 Structured Clinical Trial Protocol Standard, Release 1.0 ANSI/HL7 SPL R1.0-2004 HL7 Structured Product Labeling Standard, Release 1.0 UNITED STATES NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST) FIPS PUB 46 Data Encryption Standard FIPS PUB 81 DES Modes of Operation OTHER REFERENCES Anderson, LL “A “natural” volume-dose histogram for brachytherapy”, Medical Physics 13(6) pp 898-903, 1986. ANSI X9.52-1998 Triple Data Encryption Algorithm Modes of Operation, Accredited Standards Committee (ASC) X9, Financial Services BI-RADS Breast Imaging Reporting and Data System, 3rd Edition 1998, American College of Radiology. CIE Publication 15.2-1986 Colorimetry, Second Edition, Commission Internationale de l'Eclairage/ International Commission on Illumination ECMA 235 The ECMA GSS-API Mechanism, European Computer Manufacturers Association GB 18030-2000 Information Technology -- Chinese ideograms coded character set for information interchange -- Extension for the basic set, Standards Administration of China ICRU Report 50 Prescribing, Recording, and Reporting Photon Beam Therapy, International Commission on Radiation Units and Measurements, 1993 NEMA UD3-2004 Standard for Real-Time Display of Thermal and Mechanical Acoustic Output Indices on Diagnostic Ultrasound Equipment, National Electrical Manufacturers Association and American Institute of Ultrasound in Medicine IEEE 754:1985 32-bit and 64-bit Floating Point Number Representations PDF Reference PDF Reference, Fifth Edition: Adobe Portable Document Format version 1.6, Adobe Systems Incorporated TIS 620-2533 (1990) Thai Characters Code for Information Interchange, Thai Industrial Standards Institute 3 Definitions For the purposes of this Standard the following definitions apply. 3.1 Reference model definitions This Part of the Standard is based on the concepts developed in ISO 7498-1 and makes use of the following terms defined in it: a. Application Entity b. Service or Layer Service This Part of the Standard makes use of the following terms defined in ISO 7498-2: a. Data Confidentiality Note: The definition is “the property that information is not made available or disclosed to unauthorized individuals, entities or processes.” b. Data Origin Authentication Note: The definition is “the corroboration that the source of data received is as claimed.” c. Data Integrity Note: The definition is “the property that data has not been altered or destroyed in an unauthorized manner.” d. Key Management Note: The definition is “the generation, storage, distribution, deletion, archiving and application of keys in accordance with a security policy.” 3.2 Service conventions definitions This Part of the Standard makes use of the following terms defined in ISO/TR 8509: a. Primitive 3.3 DICOM introduction and overview definitions This Part of the Standard makes use of the following terms defined in PS 3.1: a. Attribute b. Command c. Data Dictionary d. Message 3.4 DICOM service class specifications This Part of the Standard makes use of the following terms defined in PS 3.4: a. Real-World Activity b. Real-World Object c. Service Class d. Service Class User e. Service Class Provider f. Service-Object Pair (SOP) Class g. Service-Object Pair (SOP) Instance h. Preformatted Grayscale Image i. Preformatted Color Image j. Related General SOP Class 3.5 DICOM data structures and encoding This Part of the Standard makes use of the following terms defined in PS 3.5: a. Data Element b. Data Element Tag c. Data Element Type d. Data Set e. Defined Term f. Enumerated Value g. Sequence of Items h. Unique Identifier (UID) 3.6 DICOM message exchange This Part of the Standard makes use of the following terms defined in PS 3.7: a. DICOM Message Service Element (DIMSE) b. DIMSE-N Services c. DIMSE-C Services 3.7 DICOM upper layer service This Part of the Standard makes use of the following terms defined in PS 3.8: a. DICOM Upper Layer Service 3.8 DICOM Information Object The following definitions are commonly used in this part of the Standard: 3.8.1 Attribute tag: 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). 3.8.2 Composite IOD: an Information Object Definition which represents parts of several entities in the DICOM Application Model. Such an IOD includes Attributes which are not inherent in the Real-World Object that the IOD represents but rather are inherent in related Real-World Objects. 3.8.3 Derived image: an image in which the pixel data was constructed from pixel data of one or more other images (source images). 3.8.4 DICOM information model: an Entity-Relationship diagram which is used to model the relationships between the Information Object Definitions representing classes of Real-World Objects defined by the DICOM Application Model. 3.8.5 DICOM application model: an Entity-Relationship diagram used to model the relationships between Real-World Objects which are within the area of interest of the DICOM Standard. 3.8.6 Information entity: that portion of information defined by a Composite IOD which 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. 3.8.7 Information object definition (IOD): a data abstraction of a class of similar Real-World Objects which defines the nature and Attributes relevant to the class of Real-World Objects represented. 3.8.8 Module: A set of Attributes within an Information Entity or Normalized IOD which are logically related to each other. 3.8.9 Multi-frame image: Image that contains multiple two-dimensional pixel planes. 3.8.10 Normalized IOD: an Information Object Definition which represents a single entity in the DICOM Application Model. Such an IOD includes Attributes which are only inherent in the Real-World Object that the IOD represents. 3.8.11 Cine run: A set of temporally related frames acquired at constant or variable frame rates. This term incorporates the general class of serialography. Note: A Cine run is typically encoded as a multi-frame image. Specialization: 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. Note: The same Attribute may be present in multiple Modules in the same IOD but not specified to be “Specialized”. Functional Group: A set of logically related Attributes that are likely to vary together. May be used in Multi-frame IODs to describe parameters which change on a per frame basis. 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. Sections 8.1 through 8.8 specify the Attributes of which the Sequence Items (Attribute Sets) of Code Sequence Attributes are constructed. 3.9 Character Handling Definitions This part of the standard makes use of the following terms defined in ISO/IEC 2011:1994: a. Coded character set; code. b. Code extension; c. Escape sequence. 3.10 Radiotherapy This Part of the Standard is based on the concepts developed in IEC 61217 and makes use of the following terms defined in it: a. FIXED REFERENCE system b. GANTRY system c. BEAM LIMITING DEVICE system d. WEDGE FILTER system e. X-RAY IMAGE RECEPTOR system f. PATIENT SUPPORT system g. TABLE TOP ECCENTRIC system h. TABLE TOP system 3.11 Macros 3.11.1 Attribute Macro: a set of Attributes that are described in a single table that is referenced by multiple Module or other tables. 3.12 Device Independent Pixel Values 3.12.1 P-Value This Part of the Standard makes use of the following terms defined in PS 3.14: a. P-Value Note: The definition is "A device independent value defined in a perceptually linear grayscale space. The output of the DICOM Presentation LUT is P-Values, i.e. the pixel value after all DICOM defined grayscale transformations have been applied. P-Values are the input to a Standardized Display System." 3.12.2 PCS-Value: Profile Connection Space Value. A device independent color value that is created by the application of the transformation specified in an ICC profile. 3.13 Codes and Controlled Terminology Definitions: This Part of the Standard makes use of the following terms defined in PS 3.16: Baseline Context Group Identifier (BCID) Defined Context Group Identifier (DCID) Context Group Context Group Version Context ID (CID) Mapping Resource Relationship Type DICOM Content Mapping Resource (DCMR) Template Template ID (TID) Value Set Baseline Template Identifier (BTID) Defined Template Identifier (DTID) Coding schemes 3.14 Reference Model Security Architecture Definitions This Part of the Standard makes use of the following terms defined in ISO 7498-2: Digital Signature Note: 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.” Data Confidentiality Note: The definition is “the property that information is not made available or disclosed to unauthorized individuals, entities or processes.” Data Origin Authentication Note: The definition is “the corroboration that the source of data received is as claimed.” Data Integrity Note: The definition is “the property that data has not been altered or destroyed in an unauthorized manner.” Key Management Note: The definition is “the generation, storage, distribution, deletion, archiving and application of keys in accordance with a security policy.” 3.15 Security Definitions This Part of the Standard makes use of the following terms defined in ECMA 235: Security Context Note: The definition is “security information that represents, or will represent a Security Association to an initiator or acceptor that has formed, or is attempting to form such an association.” 3.16 DICOM security profiles This part of the Standard makes use of the following terms defined in PS 3.15: Message Authentication Code Certificate 3.17 Multi-Dimensional Definitions 3.17.1 Reference Coordinate System (RCS): 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. 3.17.2 Fiducial: 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 data sets is a common means to establish the spatial relationship between similar objects. 3.17.3 Fiducial Point: A Fiducial Point defines a specific location of a Fiducial. A Fiducial Point is relative an image or to an RCS. 4 Symbols and abbreviations The following symbols and abbreviations are used in this Part of the Standard. ACR American College of Radiology ASCII American Standard Code for Information Interchange AE Application Entity ANSI American National Standards Institute BEV Beam’s-eye view Brachy Brachytherapy BRHC Bottom Right Hand Corner CC Counter-clockwise CDA Clinical Document Architecture (HL7) CEN TC251 Comite European de Normalisation-Technical Committee 251-Medical Informatics CCIR Consultative Committee, International Radio Chest CAD Computer-Aided Detection and/or Computer-Aided Diagnosis for chest radiography CTV Clinical target volume CW Clockwise DICOM Digital Imaging and Communications in Medicine DIMSE DICOM Message Service Element DIMSE-C DICOM Message Service Element-Composite DIMSE-N DICOM Message Service Element-Normalized DRR Digitally-reconstructed radiograph DVH Dose-volume histogram EPI Electronic Portal Image EPID Electronic Portal Imaging Device GTV Gross tumor volume Gy Gray HISPP Healthcare Information Standards Planning Panel HL7 Health Level 7 HMD Hierarchical Message Description (HL7) ICRU International Commission on Radiation Units IE Information Entity IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers IHE Integrating the Healthcare Enterprise II Instance Identifier (HL7) IOD Information Object Definition ISO International Standards Organization ITU-T International Telecommunications Union – Telecommunications Standardization Sector JIRA Japan Industries Association of Radiation Apparatus JPIP JPEG 2000 Interactive Protocol LUT Lookup Table MAC Message Authentication Code Mammography CAD Computer-Aided Detection and/or Computer-Aided Diagnosis for Mammography MeV Mega electron Volt MLC Multileaf (multi-element) collimator MSDS Healthcare Message Standard Developers Sub-Committee MU Monitor unit MV Megavolt NaN Not a Number (See IEEE 754) NEMA National Electrical Manufacturers Association OID Object Identifier (ISO 8824) OSI Open Systems Interconnection PDF Portable Document Format PTV Planning target volume R&V Record and verify RCS Reference Coordinate System ROI Region of interest RT Radiotherapy SAD Source-axis distance SCP Service Class Provider SCTP Structured Clinical Trial Protocol (HL7) SCU Service Class User SD Structured Documents (HL7) SID Source Image Receptor Distance SOD Source Object Distance SOP Service-Object Pair SPL Structured Product Labeling (HL7) SR Structured Reporting SSD Source-skin distance TLHC Top Left Hand Corner UID Unique Identifier UUID Universal Unique Identifier (ISO/IEC 11578) XDS Cross-Enterprise Document Sharing Profile (IHE) XML Extensible Markup Language 5 Conventions 5.1 Entity-relationship model 5.1.1 ENTITY 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. Figure 5.1-1 ENTITY CONVENTION 5.1.2 RELATIONSHIP 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. Figure 5.1-2 RELATIONSHIP CONVENTION 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. (a = 1, b = 1) - one source entity is related to one destination entity b. (a = 1, b = 0-n) - one source entity is related to zero or more destination entities c. (a = 1, b = 1-n) - one source entity is related to one or more destination entities d. (a = 1-n, b = 1) - one or more source entities are related to one destination entity e. (a = 1-n, b = 0-n) - one or more source entities are related to zero or more destination entities f. (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. Note: 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 which 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. 5.2 Sequences 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 which may be repeated to form a Sequence of Items. This Sequence of Items is nested in the Attribute (or Module) which precedes in the table the first member marked with a '>'. Note: 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. ...... ..... Referenced Series Sequence ..... > Series Date ..... > Series Time ..... > Series Instance UID ..... Modality .... 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 PS 3.5. Notes: 1. Some sections of the Standard often include Attributes within a Sequence of Items under the condition that a Sequence Item is present. For example, as shown in the following table, Requested Procedure ID (0040,1001) has Type 1C and is included under the condition that “Required if Sequence Item is present”: Attribute Name Tag Type Attribute Description Request Attributes Sequence (0040,0275) 3 Sequence that contains attributes from the Imaging Service Request. The sequence may have one or more Items. >Requested Procedure ID (0040,1001) 1C Identifier which identifies the Requested Procedure in the Imaging Service Request. Required if Sequence Item is present. >Scheduled Procedure Step ID (0040,0009) 1C Identifier which identifies the Scheduled Procedure Step. Required if Sequence Item is present. 2. The condition may be omitted since it is redundant with the Type of the Sequence attribute. The above example may be equivalently specified without the conditions, as illustrated in the following table: Attribute Name Tag Type Attribute Description Request Attributes Sequence (0040,0275) 3 Sequence that contains attributes from the Imaging Service Request. The sequence may have one or more Items. >Requested Procedure ID (0040,1001) 1 Identifier which identifies the Requested Procedure in the Imaging Service Request. >Scheduled Procedure Step ID (0040,0009) 1 Identifier which identifies the Scheduled Procedure Step. 5.3 Triplet Encoding of Structured Data (Retired) This section has been retired. See Section 8. 5.4 Attribute Macros 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 PS 3.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-1 Example Module Table Attribute Name Tag Type Attribute Description Attribute A (aaaa,aaaa) 1 This is an example. Attribute B Sequence (bbbb,bbbb) 1 This is an example of a Sequence Attribute >Include 'Example Macro' Table 5.4-2 In this Module, Attribute D (dddd,dddd) is Type 1 Table 5.4-2 is an example of the Attribute Macro referenced in Table 5.4-1. Table 5.4-2 Example Macro Attribute Name Tag Type Attribute Description Attribute C (cccc,cccc) 1 This is an example. Attribute D (dddd,dddd) 3 This Attribute is generally a Type 3. 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 Attribute Name Tag Type Attribute Description Attribute A (aaaa,aaaa) 1 This is an example. Attribute B Sequence (bbbb,bbbb) 1 This is an example of a Sequence Attribute. >Attribute C (cccc,cccc) 1 This is an example. >Attribute D (dddd,dddd) 1 In this Module, this Attribute has been specialized to Type 1 as indicated in Table 5.4-1. 5.5 Types and Conditions in Normalized IODs When a Normalized Information Object Definition in PS 3.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. 6 DICOM information model 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. Figure 6-1 MAJOR STRUCTURES OF DICOM INFORMATION MODEL 6.1 Information object definition 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 which 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 which includes information about related Real-World Objects is called a Composite Information Object. 6.1.1 COMPOSITE IOD A Composite IOD is an Information Object Definition which 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 which 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. 6.1.2 NORMALIZED IOD A Normalized IOD is an Information Object Definition which 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. 6.2 Attributes The Attributes of an IOD describe the properties of a Real-World Object Instance. Related Attributes are grouped into Modules which 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 PS 3.5. For specific Data Elements, the Value Representation and Value Multiplicity are specified in the Data Dictionary in PS 3.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. 6.3 On-line communication and media storage services 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 PS 3.7. For media storage interchange, Media Storage Services allow a DICOM Application Entity to invoke media storage related operations. Note: These Media Storage Services are discussed in PS 3.10. 6.3.1 DIMSE-C SERVICES DIMSE-C Services are services applicable only to a Composite IOD. DIMSE-C Services provide only operation services. 6.3.2 DIMSE-N SERVICES DIMSE-N Services are services applicable only to a Normalized IOD. DIMSE-N Services provide both operation and notification services. 6.4 DIMSE service group A DIMSE Service Group specifies one or more operations/notifications defined in PS 3.7 which are applicable to an IOD. DIMSE Service Groups are defined in PS 3.4 in the specification of a Service-Object Pair Class. 6.5 Service-object pair (SOP) class A Service-Object Pair (SOP) Class is defined by the union of an IOD and a DIMSE Service Group. The SOP Class definition contains the rules and semantics which may restrict the use of the services in the DIMSE Service Group and/or the Attributes of the IOD. The selection of SOP Classes is used by Application Entities to establish an agreed set of capabilities to support their interaction. This negotiation is performed at association establishment time as described in PS 3.7. An extended negotiation allows Application Entities to further agree on specific options within a SOP Class. Note: 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. 6.5.1 NORMALIZED AND COMPOSITE SOP CLASSES DICOM defines two types of SOP Classes, Normalized and Composite. Normalized SOP Classes are defined as the union of a Normalized IOD and a set of DIMSE-N Services. Composite SOP Classes are defined as the union of a Composite IOD and a set of DIMSE-C Services. Note: 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 PS 3.2. 6.6 Association negotiation 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 PS 3.7. 6.7 Service class specification A Service Class Specification defines a group of one or more SOP Classes related to a specific function which is to be accomplished by communicating Application Entities. A Service Class Specification also defines rules which allow implementations to state some pre-defined level of conformance to one or more SOP Classes. Applications may conform to SOP Classes as either a Service Class User (SCU) or Service Class Provider (SCP). Service Class Specifications are defined in PS 3.4. Note: Such interaction between peer Application Entities work on a 'client/server model'. The SCU acts as the 'client', while the SCP acts as the 'server'. The SCU/SCP roles are determined during association establishment. 7 DICOM model of the real-world Figures 7-1a, 7-1b and 7-3 depict the DICOM view of the Real-World which 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. Figure 7-1a DICOM MODEL OF THE REAL-WORLD Figure 7-1b DICOM MODEL OF THE REAL-WORLD - PRINT Figure 7-2a DICOM INFORMATION MODEL Figure 7-2b DICOM INFORMATION MODEL - PRINT Figure 7-2c DICOM INFORMATION MODEL - RADIOTHERAPY Figure 7-3. MODEL OF THE REAL WORLD FOR THE PURPOSE OF MODALITY-IS INTERFACE 7.1 DICOM information model The DICOM Information Model is derived from the DICOM Model of the Real-World. The DICOM Information Model presented by Figures 7-2a, 7-2b and 7-2c identify the various IODs specified by this Standard and their relationships. There is not always a one-to-one correspondence between DICOM Information Object Definitions 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 Figures 7-2a, 7-2b and 7-2c correspond to IODs defined in Annexes A through C. 7.2 Organization of annexes A, B and C Annex A defines Composite IOD's (e.g. Images) acquired on a number of Modalities (e.g. CT, MR, NM, US, CR, Secondary Capture). These Composite IOD's 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 PS 3.4. These Normalized IODs reference Module definitions found in Annex C. 7.3 Extension of the DICOM model of the real-world 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. The PS 3.17 Annex entitled Integration of Modality Worklist and Modality Performed Procedure Step in the Original DICOM Standard 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. 7.3.1 Definition of the Extensions of the DICOM Real-World Model 7.3.1.1 PATIENT A Patient is a person receiving, or registered to receive, healthcare services, or is the subject of one or more studies for some other purpose, such as research. Note: A patient may be a human or an animal. 7.3.1.2 SERVICE EPISODE AND VISIT A Service Episode is a collection of events, aggregated during an interval bounded by start and stop times (e.g. an outpatient visit or a hospitalization). The definition of the start time, stop time, and included events of a Service Episode is entirely arbitrary. A Service Episode is the context in which the treatment or management of an arbitrary subset of a Patient’s medical conditions occurs. In the context of imaging services, 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 Service Episode identifies the Certified Health Care Providers who have been delegated responsibility by one or more Healthcare Organizations to provide healthcare services to the Patient. One or more Certified Healthcare Providers (Organizations or individual persons, e.g. physician group practices, individual physicians, technologists, nurses) may be accountable for the healthcare services provided in a Service Episode. The Certified Health Care Providers are accountable to one or more Healthcare Organizations and to the Patient for the outcomes of the services provided. 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. In addition to identification of Certified Health Care Providers, it also specifies Healthcare Organization, Patient’s location(s), admission and discharge diagnoses and time boundaries of the visit. Notes: 1. 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. 2. In the context of the Modality Worklist SOP Class, only the Visit is of relevance, the attributes of the Service Episode are not defined. 3. The attributes for Visit often use the term admission. 7.3.1.3 IMAGING SERVICE REQUEST 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. In the context of the General Purpose Worklist the information provided by the Imaging Service Request supports a more general kind of request, e.g. reporting, requesting an image processing procedure on an existing examination, etc. 7.3.1.4 PROCEDURE TYPE 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. Note: The information content of this entity relates to the general identification of a Procedure Type rather than to its decomposition into the protocol(s) required to perform a specific instance of a Requested Procedure for a particular Patient. 7.3.1.5 REQUESTED PROCEDURE 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. 7.3.1.6 SCHEDULED PROCEDURE STEP 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 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. Notes: 1. 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. 2. 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. 7.3.1.7 PROCEDURE PLAN 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 preformed according to a single Protcol which may be identified by one or more Protocol Codes. The Protocols actually performed during a Procedure Step 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, but is not specified by this Standard. Note: The fact that Protocols Codes are in a given order in a Procedure Plan is not evident in Figure 7.3. However, the order of Protocols is represented at the syntax level (i.e. as the sequence of items present in the Protocol Code Sequence (0040,0008)). 7.3.1.8 PROTOCOL 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. Typically, the code or codes identifying a Protocol instance would be selected from a catalog of protocols. Multiple Protocols may not exist in one Scheduled Procedure Step. 7.3.1.9 MODALITY PERFORMED PROCEDURE STEP 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. Note: 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 it’s state (e.g. in progress, discontinued or completed). A Modality Performed Procedure Step is a Performed Procedure Step that results from 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, radiation dose values to which the patient has been exposed if ionizing radiation is in use, 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. 7.3.1.10 GENERAL PURPOSE SCHEDULED PROCEDURE STEP A General Purpose Scheduled Procedure Step is an arbitrarily defined scheduled unit of service, that is specified by the Procedure Plans of one or more Requested Procedures. A General Purpose Scheduled Procedure Step prescribes one Workitem that describes the procedure step to be performed. A General Purpose Scheduled Procedure Step involves applications, human resources, location, and time resources (e.g. start time, stop time, duration). Notes: 1. In this section, application is the generic term used to designate software applications and pieces of devices. 2. The status of a general Purpose Scheduled Procedure Step must not be confused with the status of the Requested Procedure or Imaging Service Request to which it belongs. One General Purpose Scheduled Procedure Step may be completed, but that does not imply that also the related Requested Procedure has reached its completion. A General Purpose Scheduled Procedure Step contains references to Composite SOP Instances or Performed Procedure Steps, which denote the information to be used for the performance of the General Purpose Scheduled Procedure Step. 7.3.1.11 GENERAL PURPOSE PERFORMED PROCEDURE STEP A general Purpose Performed Procedure step is an arbitrarily defined unit of service that has actually been performed ( not just scheduled ). Normally it corresponds to one General Purpose Scheduled Procedure step, but real-world conditions may dictate that what is actually performed does not correspond exactly with what was requested or scheduled. Note: For example, two or more General Purpose Scheduled Procedure Steps, Requested Procedures or Imaging Service Requests may have been generated by different Referring Physicians but may be satisfied by a single General Purpose Performed Procedure Step at the discretion of a Performing Physician or Operator. Alternatively, a single General Purpose Scheduled Procedure step may need to be satisfied by multiple General Purpose 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. A Requested Procedure results in the creation of zero or more General Purpose Performed Procedure Steps. A General Purpose Scheduled Procedure Step results in the creation of zero or more General Purpose Performed Procedure Steps. The General Purpose Performed Procedure Step contains information about its state. It contains information describing the performance of the general purpose procedure step of a procedure. The General Purpose Performed Procedure step contains references to zero or more Composite SOP Instances that have been created as part of the procedure step. 7.3.1.12 WORKITEM A Workitem is one of the tasks prescribed by a Procedure Plan to perform an instance of a Requested Procedure. Each General Purpose Scheduled Procedure Step will contain exactly one Workitem. The code identifying a Workitem instance would be selected from a catalog of workitem types, for example with the value of Image Processing or Interpretation. 7.3.1.13 Clinical Document 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. Human readability – A clinical document is human readable. Note: This definition is from ANSI/HL7 CDA R1.0-2000, and HL7 v3 CDA R2-2005. 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 or General Purpose Worklist contexts. 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. Notes: 1. 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 and General Purpose Worklist contexts. 2. The general class of Structured Documents is not modeled in the Real-World Model; only specific sub-classes, e.g., Clinical Documents, are modeled. 7.4 Extension of the DICOM model of the real-world for the general purpose worklist For the purpose of the General Purpose Worklist SOP Class in the Worklist Management Service Class an extension of the DICOM Model of the Real-World is made, as depicted in Figures 7.4.a and 7.4.b. This subset of the real-world model covers the requirements for the General Purpose Worklist SOP Class in the Worklist Management Service Class. Figures 7.4.a and 7.4.b are an abstract description of the real world objects involved in Workflow Management. Figure 7.4.a Model of the real world for the purpose of General Purpose Worklist interface Figure 7.4.b Model of the real world for the purpose of General Purpose Worklist interface 7.5 organizing large sets of information 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-2. Figure 7.5-1 EXTENSION OF THE REAL-WORLD MODEL WITH CONCATENATIONS AND DIMENSIONS 7.5.1 CONCATENATION 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 the Concatenation UID (0020,9133). 7.5.2 DIMENSION ORGANIZATION The Dimension Organization contains a set of dimensions. A dimension is a set of attributes which change on a per-frame basis in a manner which is known before the image is acquired, which are defined by the generating application and which 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 can use the order of dimensions for guidance when presenting images. The first item of the Dimension Index Sequence shall be the slowest varying index. Note: See Multi-frame Dimension Module section (C.7.6.17) for an example. 7.6 EXTENSION OF THE DICOM MODEL OF THE REAL WORLD FOR CLINICAL TRIALS The DICOM Model of the Real World is extended for Clinical Trials 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 IOD. Attributes of the Clinical Trial Time Point object are represented in the Clinical Trial Study Module within the Study IOD. The Clinical Trial Coordinating Center attribute is represented in the Clinical Trial Series Module within Image IODs. Figure 7.6-1 – DICOM MODEL OF THE REAL WORLD – CLINICAL TRIALS 7.6.1 Clinical Trial Information Entities For the purpose of Clinical Trial Information, an extension of the DICOM Model of the Real World is made, as depicted in Figure 7.6-1. 7.6.1.1 Clinical Trial Sponsor A Clinical Trial Sponsor identifies the agency, group, or institution responsible for conducting the clinical trial and for assigning a Protocol Identifier. 7.6.1.2 Clinical Trial Protocol A Clinical Trial Protocol identifies the investigational Protocol in which the Subject has been enrolled. The Protocol has a Protocol Identifier and Protocol Name. 7.6.1.3 Clinical Trial Subject A Clinical Trial Subject identifies the Patient who is enrolled as a Subject in the investigational Protocol. 7.6.1.4 Clinical Trial Site A Clinical Trial Site identifies the location or institution at which the Subject is treated or evaluated and which is responsible for submitting clinical trial 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. 7.6.1.5 Clinical Trial Time Point The Clinical Trial Time Point identifies an imaging Study within the context of 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. 7.6.1.6 Clinical Trial Coordinating Center 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. 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. 7.7 Extension of the DICOM model of the real-world for hanging protocols The DICOM Model of the Real World is extended for Hanging Protocols with the addition of an entity that is separate from the rest of the DICOM Real World objects, as shown in Figure 7.7-1. A Hanging Protocol is not associated with any specific objects in the existing DICOM Information model, because it is not associated with a specific patient. There is no hierarchy applied to Hanging Protocol objects. Figure 7.7-1 DICOM MODEL OF THE REAL WORLD – HANGING PROTOCOL 7.7.1 Hanging Protocol Information Entity A Hanging Protocol 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). 8 Encoding of Coded Entry Data 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 which 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. Note: 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 Interventional 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, the Code Value, and Code Meaning. 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 which are suggested and may be used, but are not required to be used. A Defined Context Group lists codes for terms which 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 PS 3.16. Context Groups consist of lists of contextually related coded concepts, including the Code Value (0008,0100) and Coding Scheme Designator (0008,0102). Each concept is unqiue within the Context Group and identified by its Code Value (0008,0100) and Coding Scheme Deisgnator (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 PS 3.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 Group Identifiers (CID). 8.1 Code Value The 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). Note: The Code Value is typically not a natural language string, e.g. “T-04000”. 8.2 Coding Scheme Designator and Coding Scheme Version 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 PS 3.16. Other coding scheme designators, for both private and public coding schemes, may be used. 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). Notes: 1. Typical coding schemes used in DICOM include “DCM” for DICOM defined codes, “SNM3” for SNOMED version 3, “SRT” for SNOMED-RT, and “LN” for LOINC. 2. Coding scheme designators beginning with “99” and the coding scheme designator “L” are defined in HL7 V2 to be private or local coding schemes. 3. 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, Code Value, and Code Meaning to support interoperation of the private codes with other systems. 4. It is highly recommended that local or non-standard coding schemes be identified in the Coding Scheme Identification Sequence. The attribute Coding Scheme Version (0008,0103) may be used to identify the version of a coding scheme if necessary to resolve ambiguity in the Code Value (0008,0100) or Code Meaning (0008,0104), or if the Code Value does not appear in all versions of the Coding Scheme identified by the Coding Scheme Designator. In previous editions of the DICOM Standard, a provisional Coding Scheme Identifier of "99SDM" was used for SNOMED codes that were used in DICOM. Consequently, when a Coding Scheme Designator (0008,0102) of “99SDM” is encountered, it shall be treated as equivalent to “SNM3” for the purpose of interpreting Code Value (0008,0100). A Coding Scheme Designator (0008,0102) of “99SDM” or “SNM3” is defined to identify the SNOMED Version 3 Coding Scheme unambiguously, hence the condition for inclusion of Coding Scheme Version (0008,0103) is explicitly not satisfied. 8.3 Code Meaning The Code Meaning (0008,0104) is text which has meaning to a human and which conveys the meaning of the term defined by the combination of Code Value and Coding Scheme Designator. 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), 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) 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. 8.4 Mapping Resource 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: “DCMR”= “DICOM Content Mapping Resource”, "SDM"= "SNOMED DICOM Microglossary" (Retired). PS 3.16 specifies the DICOM Content Mapping Resource (DCMR). Note: Unless otherwise specified, the DCMR is the source of all Context Groups and Templates specified in this Standard. 8.5 Context Group Version Context Group Version (0008,0106) conveys the version (as a datetime value) of the Context Group identified by Context Identifier (0008,010F). 8.6 Context Identifier 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) and Code Meaning (0008,0104) were selected , or to which the Code Value (0008,0100) and Code Meaning (0008,0104) have been added as a private Context Group extension (see Section 8.7) . Note: Privately defined Context Groups are not identified by Context Identifier and Mapping Resource. 8.7 Context Group Extensions Context Group Extension Flag (0008,010B) may be used to designate a Code Value/Code Meaning pair as a selection from a private extension of a Context Group. If the Context Group Extension Flag 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 Notes: 1. These Attributes provide the means for implementations to extend code sets conveniently, while preserving referential integrity with respect to the original Context Group Version. 2. 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. 8.8 Standard Attribute Sets for Code Sequence Attributes 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. Note: The instruction “ Include ‘Code Sequence Macro’ Table 8.8-1” may be used in an Information Object Definition 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 ‘Code Sequence Macro’ Table 8.8-1” 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 sent. Table 8.8-1 Common Attribute Set for Code Sequence Attributes (Invoked as “Code Sequence Macro”) Attribute Name Tag Type Attribute Description BASIC CODED ENTRY ATTRIBUTES Code Value (0008,0100) 1C See Section 8.1. Required if a sequence item is present. Coding Scheme Designator (0008,0102) 1C See Section 8.2. Required if a sequence item is present. Coding Scheme Version (0008,0103) 1C See Section 8.2. Required if a sequence item is present and the value of Coding Scheme Designator (0008,0102) is not sufficient to identify the Code Value (0008,0100) unambiguously. Code Meaning (0008,0104) 1C See Section 8.3. Required if a sequence item is present. ENHANCED ENCODING MODE Context Identifier (0008,010F) 3 See Section 8.6. Mapping Resource (0008,0105) 1C See Section 8.4. Required if Context Identifier (0008,010F) is present. Context Group Version (0008,0106) 1C See Section 8.5. Required if Context Identifier (0008,010F) is present. Context Group Extension Flag (0008,010B) 3 Indicates whether the Code Value/Coding Scheme/Code Meaning is selected from a private extension of the Context Group identified in Context Identifier (0008,010F). See Section 8.7 of this Part. Enumerated Values: “Y”, ”N” Context Group Local Version (0008,0107) 1C See Section 8.7. Required if the value of Context Group Extension Flag (0008,010B) is "Y". . Context Group Extension Creator UID (0008,010D) 1C 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". 9 TEMPLATE IDENTIFICATION MACRO (Retired) Section 9 was defined in a previous version of the DICOM Standard (see PS3.3-2004). The Section is now retired, and its contents have been consolidated into Section C.18.8. 10 MISCELLANEOUS MACROS 10.1 Person Identification Macro 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. Notes: 1. This macro is typically invoked within a Sequence Item used to identify an individual such as a physician or a device operator. 2. 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. 3. No Baseline, Defined or Enumerated Context Groups 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. 4. The organization is specified by either a coded sequence or a free text name but not both. Table 10-1 Person Identification Macro Attributes Description Attribute Name Tag Type Attribute Description Person Identification Code Sequence (0040,1101) 1 A coded entry which identifies a person. The Code Meaning attribute, though it will be encoded with a VR of LO, may be encoded according to the rules of the PN VR (e.g. caret ‘^’ delimiters shall separate name components), except that a single component (i.e. the whole name unseparated by caret delimiters) is not permitted. Name component groups for use with multi-byte character sets are permitted, as long as they fit within the 64 characters (the length of the LO VR). One or more Items may be permitted in this Sequence. >Include ‘Code Sequence Macro’ Table 8.8-1 No Baseline Context ID is defined. Person's Address (0040,1102) 3 Person's mailing address Person's Telephone Numbers (0040,1103) 3 Person's telephone number(s) Institution Name (0008,0080) 1C Institution or organization to which the identified individual is responsible or accountable. Shall not be present if Institution Code Sequence (0008,0082) is present. Institution Address (0008,0081) 3 Mailing address of the institution or organization to which the identified individual is responsible or accountable. Institution Code Sequence (0008,0082) 1C Institution or organization to which the identified individual is responsible or accountable. Shall not be present if Institution Name (0008,0080) is present. Only a single Item shall be permitted in this Sequence. >Include ‘Code Sequence Macro’ Table 8.8-1 No Baseline Context ID is defined. 10.2 CONTENT ITEM MACRO 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. Note: Comparing a Content Item to a native DICOM Data Element, the Concept Name Code Sequence 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. 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). Note: 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. 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 Description Attribute Name Tag Type Attribute Description Value Type (0040,A040) 1 The type of the value encoded in this name-value Item. Defined Terms: DATETIME DATE TIME PNAME UIDREF TEXT CODE NUMERIC Concept Name Code Sequence (0040,A043) 1 Coded concept name of this name-value Item. >Include ‘Code Sequence Macro’ Table 8.8-1 No Baseline Context ID is defined. DateTime (0040,A120) 1C Datetime value for this name-value Item. Required if Value Type (0040,A040) is DATETIME. Date (0040,A121) 1C Date value for this name-value Item. Required if Value Type (0040,A040) is DATE. Time (0040,A122) 1C Time value for this name-value Item. Required if Value Type (0040,A040) is TIME. Person Name (0040,A123) 1C Person name value for this name-value Item. Required if Value Type (0040,A040) is PNAME. UID (0040,A124) 1C UID value for this name-value Item. Required if Value Type (0040,A040) is UIDREF. Text Value (0040,A160) 1C Text value for this name-value Item. Required if Value Type (0040,A040) is TEXT. Concept Code Sequence (0040,A168) 1C Coded concept value of this name-value Item. Required if Value Type (0040,A040) is CODE. >Include ‘Code Sequence Macro’ Table 8.8-1 No Baseline Context ID is defined. Numeric Value (0040,A30A) 1C Numeric value for this name-value Item. Required if Value Type (0040,A040) is NUMERIC. Measurement Units Code Sequence (0040,08EA) 1C Units of measurement for a numeric value in this name-value Item. Required if Value Type (0040,A040) is NUMERIC. >Include ‘Code Sequence Macro’ Table 8.8-1 Baseline Context ID 82 10.3 Image SOP Instance Reference Macro Table 10-3 IMAGE SOP INSTANCE REFERENCE MACRO ATTRIBUTES Attribute Name Tag Type Attribute Description Referenced SOP Class UID (0008,1150) 1 Uniquely identifies the referenced SOP Class. Referenced SOP Instance UID (0008,1155) 1 Uniquely identifies the referenced SOP Instance. Referenced Frame Number (0008,1160) 1C Identifies the frame numbers within the Referenced SOP Instance to which the reference applies. The first frame shall be denoted as frame number 1. Note: This Attribute may be multi-valued. 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. Referenced Segment Number (0062,000B) 1C 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. 10.4 Series and Instance Reference Macro Table 10-4 defines the Attributes that list Series and SOP Instances within those Series. Table 10-4 SERIES AND INSTANCE REFERENCE MACRO ATTRIBUTES Attribute Name Tag Type Attribute Description Referenced Series Sequence (0008,1115) 1 Sequence of Items each of which includes the Attributes of one Series. One or more Items shall be present. >Series Instance UID (0020,000E) 1 Unique identifier of the Series containing the referenced Instances. >Referenced Instance Sequence (0008,114A) 1 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. One or more Items shall be present. >>Referenced SOP Class UID (0008,1150) 1 Uniquely identifies the referenced SOP Class. >>Referenced SOP Instance UID (0008,1155) 1 Uniquely identifies the referenced SOP Instance. 10.5 General Anatomy Macros Tables 10-5 through 10-7 describe 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 difference between the three macros is the Type of the Anatomic Region Sequence (0008,2218) attribute. Table 10-8 describe the attributes for the coding of the principal structure only. The invocation of these macros may specify Baseline or Defined Context IDs 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). Note: 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). Table 10-5 GENERAL ANATOMY MANDATORY MACRO ATTRIBUTES Attribute Name Tag Type Attribute Description Anatomic Region Sequence (0008,2218) 1 Sequence that identifies the anatomic region of interest in this Instance (i.e. external anatomy, surface anatomy, or general region of the body). Only a single Item shall be permitted in this sequence. >Include ‘Code Sequence Macro’ Table 8.8-1 Context ID may be defined in the macro invocation. >Anatomic Region Modifier Sequence (0008,2220) 3 Sequence of Items that modifies the anatomic region of interest of this Instance One or more Items may be included in this Sequence. >>Include ‘Code Sequence Macro’ Table 8.8-1 Defined Context ID is 2, unless otherwise defined in the macro invocation. Include ‘Primary Anatomic Structure Macro’ Table 10-8 Context ID may be defined in the macro invocation. Table 10-6 GENERAL ANATOMY REQUIRED MACRO ATTRIBUTES Attribute Name Tag Type Attribute Description Anatomic Region Sequence (0008,2218) 2 Sequence that identifies the anatomic region of interest in this Instance (i.e. external anatomy, surface anatomy, or general region of the body). Zero or one Item may be present in this Sequence. >Include ‘Code Sequence Macro’ Table 8.8-1 Context ID may be defined in the macro invocation. >Anatomic Region Modifier Sequence (0008,2220) 3 Sequence of Items that modifies the anatomic region of interest of this Instance One or more Items may be included in this Sequence. >>Include ‘Code Sequence Macro’ Table 8.8-1 Defined Context ID is 2, unless otherwise defined in the macro invocation. Include ‘Primary Anatomic Structure Macro’ Table 10-8 Context ID may be defined in the macro invocation. Table 10-7 GENERAL ANATOMY OPTIONAL MACRO ATTRIBUTES Attribute Name Tag Type Attribute Description Anatomic Region Sequence (0008,2218) 3 Sequence that identifies the anatomic region of interest in this Instance (i.e. external anatomy, surface anatomy, or general region of the body). Only a single Item shall be permitted in this sequence. >Include ‘Code Sequence Macro’ Table 8.8-1 Context ID may be defined in the macro invocation. >Anatomic Region Modifier Sequence (0008,2220) 3 Sequence of Items that modifies the anatomic region of interest of this Instance One or more Items may be included in this Sequence. >>Include ‘Code Sequence Macro’ Table 8.8-1 Defined Context ID is 2, unless otherwise defined in the macro invocation. Include ‘Primary Anatomic Structure Macro’ Table 10-8 Context ID may be defined in the macro invocation. Table 10-8 PRIMARY ANATOMIC STRUCTURE MACRO ATTRIBUTES Primary Anatomic Structure Sequence (0008,2228) 3 Sequence of Items that identifies the primary anatomic structure(s) of interest in this Instance. One or more Items may be included in this Sequence. >Include ‘Code Sequence Macro’ Table 8.8-1 Context ID may be defined in the macro invocation. >Primary Anatomic Structure Modifier Sequence (0008,2230) 3 Sequence of Items that modifies the primary anatomic structure of interest in this Instance. One or more Items may be included in this Sequence. >>Include ‘Code Sequence Macro’ Table 8.8-1 Defined Context ID is 2. 10.6 Request Attributes Macro Table 10-9 REQUEST ATTRIBUTES MACRO ATTRIBUTES Attribute Name Tag Type Attribute Description Requested Procedure ID (0040,1001) 1 Identifier that identifies the Requested Procedure in the Imaging Service Request. Accession Number (0008,0050) 3 An identifier of the Imaging Service Request for this Requested Procedure. Study Instance UID (0020,000D) 3 The unique identifier for the Study provided for this Requested Procedure. Referenced Study Sequence (0008,1110) 3 Uniquely identifies the Study SOP Instances associated with this SOP Instance. One or more items may be included. >Referenced SOP Class UID (0008,1150) 1 Uniquely identifies the referenced SOP Class >Referenced SOP Instance UID (0008,1155) 1 Uniquely identifies the referenced SOP Instance. Requested Procedure Description (0032,1060) 3 Institution-generated administrative description or classification of Requested Procedure. Requested Procedure Code Sequence (0032,1064) 3 A sequence that conveys the Procedure Type of the requested procedure. The Requested Procedure Code Sequence shall contain only a single item. >Include ‘Code Sequence Macro’ Table 8.8-1 No Baseline Context ID is defined. Reason for the Requested Procedure (0040,1002) 3 Reason for requesting this procedure. Reason for Requested Procedure Code Sequence (0040,100A) 3 Coded Reason for requesting this procedure. One or more sequence items may be present. >Include ‘Code Sequence Macro’ Table 8.8-1 Context ID may be defined in the macro invocation. Scheduled Procedure Step ID (0040,0009) 1 Identifier that identifies the Scheduled Procedure Step. Scheduled Procedure Step Description (0040,0007) 3 Institution-generated description or classification of the Scheduled Procedure Step to be performed. Scheduled Protocol Code Sequence (0040,0008) 3 Sequence describing the Scheduled Protocol following a specific coding scheme. This sequence contains one or more Items. >Include ‘Code Sequence Macro’ Table 8.8-1 Context ID may be defined in the macro invocation. >Protocol Context Sequence (0040,0440) 3 Sequence that specifies the context for the Scheduled Protocol Code Sequence Item. One or more items may be included in this sequence. >>Include ‘Content Item Macro’ Table 10-2 Context ID may be defined in the macro invocation. >> Content Item Modifier Sequence (0040,0441) 3 Sequence that specifies modifiers for a Protocol Context Content Item. One or more items may be included in this sequence. See Section C.4.10.1. >>>Include ‘Content Item Macro’ Table 10-2 Context ID may be defined in the macro invocation. 10.7 BASIC PIXEL SPACING CALIBRATION MACRO Table 10-10 defines the Attributes for the Basic Pixel Spacing Calibration Macro. Table 10-10 BASIC PIXEL SPACING CALIBRATION MACRO ATTRIBUTES Attribute Name Tag Type Attribute Description Pixel Spacing (0028,0030) 1C 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 10.7.1.1 and 10.7.1.3. Pixel Spacing Calibration Type (0028,0402) 3 The type of correction for the effect of geometric magnification or calibration against an object of known size, if any. See 10.7.1.2. Pixel Spacing Calibration Description (0029,0404) 1C A free text description of the type of correction or calibration performed. Notes: 1. In the case of correction, the text might include description of the assumptions made about the body part and geometry and depth within the patient. 2. in the case of calibration, the text might include a description of the fiducial and where it is located (e.g., “XYZ device applied to the skin over the greater trochanter”). 3. Though it is not required, the Device Module may be used to describe the specific characteristics and size of the calibration device. Required if Pixel Spacing Calibration Type (0028,0402) is present. 10.7.1 Basic Pixel Spacing Calibration Macro Attribute Descriptions 10.7.1.1 Pixel Spacing The Pixel Spacing (0028,0030) attribute specifies the physical distance in the patient between the center of each pixel. If 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 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,0402) 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. Notes: 1. Imager Pixel Spacing (0018,1164) is a required attribute in DX family IODs. 2. Nominal Scanned Pixel Spacing (0018,2010) is a required attribute in Multi-frame SC family IODs 10.7.1.2 Pixel Spacing Calibration Type The Pixel Spacing Calibration Type (0028,0402) attribute The type of correction for the effect of geometric magnification or calibration against an object of known size, if any. Enumerated Values: GEOMETRY the Pixel Spacing (0028,0030) values account for assumed or known geometric magnification effects and correspond to some unspecified depth within in 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. FIDUCIAL 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 10.7.1.3 Pixel Spacing Value Order 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 following example: Pixel Spacing = Row Spacing \ Column Spacing = 0.30 mm \ 0.25 mm. This description applies to: Pixel Spacing (0028,0030) Imager Pixel Spacing (0018,1164) Nominal Scanned Pixel Spacing (0018,2010) Image Plane Pixel Spacing (3002,0011) Compensator Pixel Spacing (300A,00E9) Detector Element Spacing (0018,7022) Presentation Pixel Spacing (0070,0101) Printer Pixel Spacing (2010,0376) Object Pixel Spacing in Center of Beam (0018,9404) 10.8 SOP Instance Reference Macro Table 10-11 specifies the attributes that reference an SOP instance. Table 10-11 SOP INSTANCE REFERENCE MACRO ATTRIBUTES Attribute Name Tag Type Description Referenced SOP Class UID (0008,1150) 1 Uniquely identifies the referenced SOP Class. Referenced SOP Instance UID (0008,1155) 1 Uniquely identifies the referenced SOP Instance. 10.9 Content Identification Macro Table 10-12 describe the attributes for identifying a SOP Instance potentially created by a human user interacting with an application. Table 10-12 CONTENT IDENTIFICATION MACRO Attribute Name Tag Type Attribute Description Instance Number (0020,0013) 1 A number that identifies this SOP Instance. Content Label (0070,0080) 1 A label that is used to identify this SOP Instance. Content Description (0070,0081) 2 A description of the content of the SOP Instance. Content Creator’s Name (0070,0084) 2 Name of operator (such as a technologist or physician) creating the content of the SOP Instance. Content Creator’s Identification Sequence (0070,0086) 3 Identification of the person who created the real world value mapping. Only a single item shall be present in this sequence. > Include Person Identification Macro Table 10-1 Annex A Composite information object definitions (Normative) A.1 Elements of an information object definition Each Composite Information Object Definition is composed of the following Sections a. IOD Description b. IOD Entity-Relationship Model IOD Module Table Optionally, a Functional Group Macros Table used by the Multi-frame Functional Groups Module Sections A.1.1 through A.1.3 of this document define the requirements of a) through d) above. A.1.1 IOD Description This Section provides a brief description of the IOD. Specifically, this description includes:  The Real-World Object which is represented by the IOD  Information as to the scope of the represented object if appropriate A.1.2 IOD Entity-Relationship Model This Section of an IOD provides the Entity-Relationship (E-R) Model which 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. Even though composite instances are sent 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 of the 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. Sections A.1.2.1 through A.1.2.10 describe the Information Entities (IE) which comprise the Composite Instance IODs defined in this Annex. 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAABAAAAPgAAAAAAAAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAD////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////9//////////7///8hAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAAP7///8iAAAA/v///yQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAD+////LwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAAP7///83AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAA/v///z8AAABAAAAAQQAAAP7//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////08AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA/////wkAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgD/////CgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjAAAALRQAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAP////8LAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4AAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANgAAAAAQAAAAAAAA/v///wIAAAD+////BAAAAP7////+////BwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAA/v////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////8BAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZAACAAAAAAAAAAgAWUQAAL8xAADAJgAANBwAAAAAAAAAAAAAAAAAAAAAAADoAwAA6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/AwoAAP////8HCQIAAAAAAMAAAAAAAABGFwAAAE1pY3Jvc29mdCBXb3JkIFBpY3R1cmUACgAAAE1TV29yZERvYwAPAAAAV29yZC5QaWN0dXJlLjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/////AwAAAAQAAAABAAAA/////wIAAAAAAAAAtD0AADo1AAASAwAAAQAJAAADiQEAAAUAHAAAAAAAFAAAACYGDwAeAP////8EABQAAABXb3JkDgBNaWNyb3NvZnQgV29yZAUAAAALAgAAAAAFAAAADALrA2EFHAAAAPsCEAAHABQADwAKAAEAaQAPAAMAAAAAAAAAAAAsAABA8f8CACwADAAGAE4AbwByAG0AYQBsAAAAAgAAAAwAbUgJBHNICQR0SAkEAAAAAAAAAAAAAAAAAAAAAAAAPABBQP